Copyright © 2005, 2007 Xinet Inc.

Contents

Introduction...................................................................................................................... 1
What WebNative does 1
WebNative features 1
WebNative Venture features 1
Customizing WebNative 2
Software and hardware requirements 2
Conventions 2
On Unix systems 3
On Windows systems 3
Where to look for technical information 3
Quick start 4

1. Licensing, installation and client enhancements ......................................................... 5

Note to those installing FullPress and WebNative products for the first time: 5
Note to those adding WebNative Venture or other upgrades to a pre-existing
WebNative installation: 5
Installing on Sun Solaris 5
Installing on SGI 7
Installing on Mac OS X system 8
Installing on a Windows 2000 or Windows 2003 system 9
Installing on a Linux system 14
About WebNative client extensions and plug-ins for WebNative clients 16
Setting Preferences for WebNative XT (QuarkXPress) 18
Setting Preferences for WebNative ID (InDesign CS,CS2 and CS3) 18
Setting WebNative ID defaults 19
WebNative ID file settings 19
Without a FullPress volume mounted 19
With a FullPress volume mounted 20
About Microsoft Office previews 20
Mac OS X servers 20
Linux servers 21
Solaris on Sparc: Solaris 9 and later 21
Windows servers 22
Mac OS X servers 22
Linux and Solaris servers 22
Other client production extensions and plug-ins 23
Removing WebNative from the server 24

2. Selecting, installing, and configuring a web server ................................................... 27

The configure.apache script 27
Apache on Solaris 27
Apache on IRIX 28
Apache on Mac OS X 28
Apache on Linux 28
Apache on Windows 2000 and Windows 2003 28

iii
 : Contents

Configuring a non-supported web server 28

Setting up directory services for WebNative 29

3. WebNative configuration ........................................................................................... 31

4. General WebNative administration............................................................................ 33

Overview 33
Basic administration steps 33
Authenticating as the administrator 33
Making GUI selections 34
User summary 35
Adding users 35
Changing attributes for existing users 37
Giving users access to volumes 38
Configuring a user’s styles 43
Using volumestyles 48
Configuring a user’s plugins 48
Shopping basket 50
Modifying access to user volumes 52
Removing access privileges to a user volume 52
Creating and editing groups 53
Deleting users or groups 53
Enabling Subadministrators 53
Changing the nativeadmin password 55
Viewing WebNative access logs 55

5. File system organization for Webnative..................................................................... 63

Strategy 1: Customers have access to active and archived jobs 63
Strategy 2: Customers only have access to archived jobs 64
Strategy 3: You keep tight control over files customers can see 64
Strategy 4: You do everything by ticket number 66

6. WebNative Security ................................................................................................... 69

Overview 69
Some groundwork 69
Securing your WebNative server 71
Other security measures 73
Links and other reading 79

7. Archiving to disk using the WebNative Suite............................................................ 81

Option 1: One big raid, one big WebNative Venture volume 81
Option 2: One raid, one JBOD (or old raid), two or more venture volumes,
operator control 82
Option 3: One production area, one strict archive area, strict migration policies 82
Grooming 83

8. WebNative Venture overview .................................................................................... 85

What does a database provide? 85
How does WebNative Venture work? 85

iv
 What database does WebNative Venture use? 86
How do you enable the database? 86

9. WebNative Venture statistics and operation — the Database tab ............................. 87

Volumes setting summary 87
Enabling the database on volumes 88
Database administration 90
What the fields in the Database GUI show 90
WebNative Venture statistics 94
Configuring the database daemons 95
Backing up and restoring data 97
More information about the dblogd(1M) daemon 100
Unnecessary webdblog files 102
Using the dblogd.conf file for setting WebNative Venture preferences 105
Settings written to the dblogd.conf file by the nativeadmin GUI 105
Settings added to the dblogd.conf file by users 106

10. WebNative Venture data formats — the Data Fields tab ...................................... 107
Data Field names 108
Data Field types 108
Data Field descriptions 109
Indexed and FullText indexed Keyword tables 109
XMP Data Fields 109
Adding Data Fields 109
Modifying or editing Data Fields 120
Deleting Data Fields 121
Establishing Data Field Sets 122
Enabling Indexed and FullText searching of Keywords 124

11. WebNative Venture templates — the Templates tab .............................................. 127

Viewing existing templates 127
Adding templates 128
Editing templates 130
Deleting templates 130

12. Assigning templates to and customizing them for individual

users — the UserPerms tab ................................................................................... 131
Adding permission sets 131
Editing or deleting permission sets 134
Assigning templates and permission sets to users 135
Uploader: behind the scenes 135

13 Actions and Trigger Sets quick-start guide ............................................................. 137

Definitions 137
Creating your first WebNative Venture Trigger Set 137
Testing the Trigger Set 144
Removing Trigger Sets and their Trigger Rules 144

14. Trigger Set Configuration ...................................................................................... 147

Planning a WebNative Venture Trigger Set 147
How do Trigger Sets actually work? 147

v
 : Contents

Creating Settings for Actions 149

List of Actions 150
archive 150
compare 150
copy 151
email 151
move 153
print 154
remove 154
setdatafield 154
transfer 154
movetree 155
Using Trigger Sets 159
Logging for Trigger Sets 165

15. Trigger Set Customization .................................................................................... 167

Some details about Trigger Sets 167
Files used in Trigger Sets 169
Files used for Action GUI information 171
The Action .buildconfig files 171
Administrative settings files 172
Log files 172
Example: Customizing an Action that ships with WebNative Venture 172
Troubleshooting WebNative Venture Trigger Sets 174
Advanced troubleshooting of WebNative Venture Triggers and Actions 174
Background for writing your own Actions 176

16. How WebNative reads data from files ................................................................... 179

IPTC/NAA Metadata and WebNative Venture 179
XMP Metadata and WebNative Venture 179
Background: How Metadata is stored in the WebNative Venture database 186

17. Importing data into WebNative Venture ................................................................ 189

Introduction 189
The import command 189
Importing from a Cumulus data base 198

18. Using the export function in WebNative Venture .................................................. 201

19. Using WebNative Venture and FlashNet................................................................ 207

When do existing FlashNet indices get read? 207
What kind of previews are stored for files archived with FlashNet? 207
What’s special about large previews? 207
Should globald keep running? 208
How do the archivefile, archivemedia, archivepath, backupfile and backuppath
tables work? 208
How can I resync my archived files? 209

20. Troubleshooting WebNative Venture ..................................................................... 213

When the file system and the database don't match 213

vi
 Other important questions to ask when troubleshooting Venture issues 214
Further steps for troubleshooting 216
The venture.log and venturelog.old files 218
The fpod_vlog file 218
The SERVER.err file 219
The at_log file 219
Logs from WebNative Venture queues 219

Appendices

A. Command-line manual pages.................................................................................. 223

B. Database synchronization ....................................................................................... 243

Syncs initiated using the Volume tab 243
Scheduled syncs 247
Syncs done while browsing 247
Syncs: to -delnorm or not to -delnorm 248

C. Credits and trademarks............................................................................................ 251

Limited warranty on media and manual 251
Disclaimers of warranty 251
Xinet software license 252

E. Endbenutzer-Lizenzvertrag für XINET-Software .................................................. 253

Index ............................................................................................................................ 255

vii
 : Contents

viii
 What WebNative does

Introduction

This manual for WebNative® and WebNative Venture system administrators provides
instructions for installing, configuring, maintaining, and customizing the Xinet® WebNative
and WebNative Venture software on a server.

What WebNative does Xinet’s asset-management and collaboration software, WebNative, provides secure, remote
access to files on a server, while keeping the production workflow efficient and hassle-free.
Customers, production partners and on- or off-site staff use WebNative to access por-
tions of the FullPress file system through a standard web browser and Internet connection.
After a password-protected login, users can download, upload, and repurpose their assets
from any location, 24 hours a day.

WebNative lets you provide a central base of operations for people who need to collaborate
across multiple sites or from remote locations, making it easy for them to access files and
design new documents. Some firms have used WebNative to build sophisticated image
libraries; while others have set up distribution centers for corporate brand management.
Many sites use WebNative Venture to automate processes in rights management, production
and client-facing web services.

Password-protected security and access control lists keep proprietary information safe,
ensuring each of your WebNative users has access only to the portion of the file system and
archives where their data is stored. Users find the assets they need by browsing through file
previews or using the WebNative search engine to find files. Found assets can be collected
in a shopping basket and downloaded in a single batch, directly to the user’s desktop. When
a new job is completed, users can upload it, and any associated files, directly to the server.

WebNative features • 24-hour, secure file access via the World Wide Web
• Easy to use asset search engine via a standard web browser
• Custom image ordering which allows downloading files in the most appropriate resolu-
tion, size, and image format
• Language localizations
• Mechanism to browse and search archived files and request their restoration
• Document upload function for returning completed layouts to service provider
• Flexible look and feel
• Easy to administer user permissions
• Instant Web-appropriate images from many different file types including: Alias PIX,
BARCO, BMP, Contex CT, Crosfield Studio 9000, DCS 1.0 and 2.0, DALiM CT and LW
(with masks), Eclipse TILE, EPS, EskoFot/EskoScan, JFIF (JPEG), Kodak PhotoDisk,
PDF, Photoshop Native, Scitex CT, LW, and MaskCutter, SGI Image Library, TIFF, TIFF/
IT, and a variety of raw camera
formats.

WebNative Venture • Provides complete SQL database functionality added to WebNative without typical data-
features base administration overhead.
• Allows faster searching for WebNative users upon more complex search criteria.

1
 : Introduction

• Previews of QuarkXPress, InDesign, PDF and Microsoft Office documents over the
web
• Automatically reads in XMP metadata; automatically records activity on assets.
• Writes XMP metadata into files
• Customized and unlimited number of metadata fields.
• Administrator jurisdiction over which database fields each user sees.
• Associates Triggers with Actions that automate workflows.
• Accepts data imported from Cumulous, et al.

Customizing WebNative From its inception, WebNative has been engineered so that sites could change user experi-
ences, in terms of both site appearance and functionality. Several options for customizing
WebNative exist:
• By reading through this manual, you will discover many ways to customize user experi-
ence using features built into the software, features such as user permissions that deter-
mine what is visible on a user-by-user or group-by-group basis, volume restrictions,
styles that dramatically change browser displays, built-in localization options, and shop-
ping basket plug-ins. Xinet also offers Advanced Administration workshops for those
who learn best in classroom settings. Please refer to the Help section of the Xinet web
site, www.xinet.com, for information about these classes.
• To quickly rebrand customer-facing sites, Administrators with even just a little HTML
knowledge can edit headers, footers and frames in any of the styles which ship with
WebNative.
• With more advanced knowledge of web-site development, programmers can alter both
the appearance and functionality of WebNative through Java Scripting. The Xinet Guide
to Development APIs, available for download in the Customer or Developer Support
sections of the Xinet web site, www.xinet.com, provides background information.
• More advanced programmers may also add features through shopping basket plug-in
development. Once again, the Xinet Guide to Development APIs provides details.
• WebNative Portal, a companion product to WebNative, provides the ultimate versatility
in site customization and added security. The Xinet web site, www.xinet.com provides
more information about WebNative Portal—or, ask you Authorized Xinet Integrator for
details.

Software and hardware WebNative runs on Sun Microsystems Solaris SPARC 7, 8, 9 and 10; Silicon Graphics IRIX
requirements 6.5, Mac OS X Panther, Jaguar and Tiger (Power PC and Intel); Windows, 2000 and 2003;
and Red Hat Enterprise Linux1 3, 4,and 5, 32 bit and 64 bit, AS and ES/Base and Advanced.
Xinet suggests always making sure you’re running the most recent version of FullPress
before installing WebNative or WebNative Venture.

Conventions We use several typographical conventions in this manual to help readers distinguish what
must be typed as is and what is simply a parameter to be substituted. In particular, readers
should type text set in a typewriter-like font, like this, literally. For example:

1. Please see “Installing on a Linux system” beginning on page 14 for information about additional libraries that may you may need to install before
installing Xinet software..

2
 Where to look for technical information

# more README or c:\> type README

Readers should enter this command exactly as shown above (minus the shell prompt on
Unix systems, #, or the c:\> prompt on Windows systems). Readers should substitute their
own applicable text for text set in slanted typewriter type, like this. For example, when
one sees

% ls directory_name or c:\> dir directory_name

one might type:

% ls doc or c:\> dir doc

ON UNIX SYSTEMS. The two examples given above illustrate another convention: when a
command must be issued by the superuser (root), you will see the prompt #; when a com-
mand may be issued by a normal user, you will see the prompt %. As in most documentation
for UNIX software, text references to UNIX functions have the form more(1). The word in
italic type is the name of the function; the parenthesized number is the section of the UNIX
Programmer’s Manual containing the function’s manual page.

ON WINDOWS SYSTEMS. When the manual discusses locations for files and programs, it
uses default installation path names. If you install files and programs in other locations, the
pithiness will not be the same as in this manual.

Where to look for Xinet technical information spans several volumes, with each software distribution having
technical information an appropriate guide. The guides are available for downloading in the
Maintenance section of the Xinet web site, www.xinet.com.

To help you easily find what you need, the guides are extensively indexed and cross-refer-
enced, and whenever possible, the index entries and cross references provide live links to
the appropriate pages within the PDF.

Xinet technical documentation includes:

• The FullPress Administration Guide
This guide contains information about FullPress installation, licensing, administration
and trouble-shooting. It exists in two versions, one for UNIX servers and one for Win-
dows. While it primarily contains information about file-sharing and print spooling opti-
mizations for production workflows and details about the many options available when
running FullPress, it also explains a few details fundamental to WebNative set-up.
• The Xinet Client Guide
This guide provides information to help end-users who are WebNative server clients.
It explains the growing list of Xinet utilities that help users get the most out of a Full-
Press/WebNative Venture server. It also includes tips for working within that environ-
ment when using Macintosh or Windows applications from Quark, Adobe, etc.
• Xinet PC Connectivity Guide
This guide provides information about installing, setting up and maintaining the Xinet
modified Samba software which allows Microsoft Windows clients to interact with Full-
Press and WebNative Venture.
• The WebNative and WebNative Venture Administration Guide

3
 : Introduction

This guide provides basic information about installation, licensing and WebNative
administration. It also provides information to consider before installation, such as opti-
mal file-system organization and security issues. Chapters include details about admin-
istrative settings and the most basic customization of web site look and feel.
The WebNative Venture portion of the guide includes information about the setting up
and everyday management of the WebNative Venture database, including ways to cus-
tomize data fields and control their use by users and groups. It also contains information
about automating production activities based on changes in the database and informa-
tion about importing data.
• The Xinet Guide to Development APIs
Not all sites where Xinet software is installed will need this volume. It presents informa-
tion about FullPress and WebNative that will interest programmers customizing the
products beyond ways made available through the GUIs which ship with Xinet prod-
ucts. Turn here for command-line customization and diagnostics and more significant
changes to WebNative interfaces.
• The WebNative Portal Guide
This guide explains installation, licensing and administration for WebNative Portal sites.
It also provides an overview of using WebNative Portal to customize the look and feel of
user sites and gives examples of building new functionality to even further extend the
product.
• On-line manual pages
UNIX-style on-line man(1) pages are included with UNIX distributions. While not
intended for the lay reader, they provide handy reference for more technically-advanced
administrators and for programmers who want to work with Xinet programs from the
command line. The man(1) pages are also included as part of each PDF manual.
• WebNative on-line help
Context-sensitive help buttons in the end-user interfaces and the WebNative and Web-
Native Venture administration interfaces provide information about buttons and tabs in
GUIs. For administrators, they provide quick-reference adjuncts to information in the
WebNative and WebNative Venture Administration Guide.
• Xinet TechNotes
Xinet TechNotes provide information about technical issues not included in manuals.
Like the Xinet Development APIs Guide and man(1) pages, the notes are often aimed at
those extending Xinet products beyond functionality offered in Xinet GUIs. They also
provide information on issues that change quickly or that are of a transient nature.

If you cannot solve your problems from information in the manuals, please contact your
Authorized Xinet Integrator or Xinet technical support.

Quick start If you are interested in a quick run through of WebNative features, complete the following
steps:
• Install a web server if you haven’t already done so.
• Install WebNative.
• Set up a FullPress volume which supports web images.
• Add a WebNative volume for an end-user.

4
 Installing on Sun Solaris

Chapter 1

Licensing, installation and client enhancements

The Xinet products WebNative®, WebNative® Venture, and additional WebNative® subad-
ministrator licenses all share a single license string with FullPress®. If you are buying Full-
Press and WebNative products at the same time, the license string you receive from Xinet
(or, for Windows and Linux installations, the dongle) will activate all software packages. If
you are upgrading any products, you will have to call Xinet to receive a new license string
which will enable the software packages. Enter the new license string in the licensing dia-
log box of the FullPress GUI on your server, then click on the Enter New License button.
After entering the new license string for a WebNative product, you do not have to restart
FullPress, unless you are adding more FullPress users.

You can call Xinet for a license string at the following numbers:
• In the United States at 510 845-0555 (6:00 AM–6:00 PM PST)
• In Germany at +49 (0)89.44 47 81 0 (09.00–17.00 CEST)

Installation procedures vary according to the platform upon which you are installing the
software. Directions for each platform follow.

NOTE TO THOSE INSTALLING FULLPRESS AND WEBNATIVE PRODUCTS FOR THE FIRST TIME:

You will have already licensed WebNative, WebNative Venture and any other upgrades dur-
ing FullPress installation.

NOTE TO THOSE ADDING WEBNATIVE VENTURE OR OTHER UPGRADES TO A PRE-EXISTING

WEBNATIVE INSTALLATION: If you are upgrading WebNative, please follow the licensing
procedure described above before going through the installation process. During installa-
tion, WebNative Venture and other WebNative upgrades will install cleanly on top of your
current WebNative software. As with all Xinet products, the upgrade with preserve all pre-
vious configuration information, including an existing FullText Index.

Note to those interested in displaying previews of Microsoft Office documents: With version
8.03 of WebNative Venture, Xinet introduced web browser previews of Microsoft Office
documents. If you are interested in this functionality, you can save a bit of time by installing
OpenOffice.org software before your WebNative Venutre installation or upgrade. “About
Microsoft Office previews” beginning on page 20 provides details.

Installing on Sun Solaris From a local Sun Solaris CD ROM drive

1. Log in as root.
2. If your CD ROM drive is mounted on the machine upon which you want to install
WebNative, choose one of the following methods to initiate installation:
a. Use the Solaris File Manager to open the contents of the CD ROM drive and click
on the installwebnative icon.

5
 Chapter 1: Licensing, installation and client enhancements

or
b. Open a shell window and cd into the mount point of the CD ROM. Then, type:

# cd SOL.WN
# ./installwebnative
(If you are not running Open Windows, pkgadd(1M) will begin automatically at this
point.)
3. The Action:Run window may appear. Ignore the options/arguments window and click
OK.
4. WebNative should install automatically.
As soon as installation is complete, your web browser should automatically launch,
pointing at the WebNative welcome.html which will provide information regarding
setting up WebNative.
If you can’t get Xinet software to install correctly, call Xinet Technical Support at the
numbers listed on page 5 or email help@xinet.com.

From a remote Solaris CD ROM drive

If your CD ROM drive is on a remote machine, copy the entire contents of the SOL_WN
folder on the FullPress/WebNative CD ROM to a local directory. Then, follow the direc-
tions for installation from a local drive.

From the web

If you are currently enrolled in the Xinet Maintenance and Support program, you may
download new software versions over the web. (Xinet products ship with a one-year mem-
bership.) To download software:

1. Direct your browser to: http://www.xinet.com. Click on the Log in link and log in to
access product updates. If you do no know your login information, please contact your
Xinet Integrator or help@xinet.com.
2. Once you are logged in, click on Downloads, and then, Released Software.
3. Download the appropriate version of software for the operating system on your server.
Although an inappropriate version won’t install, you’ll waste downloading time if you
choose the wrong one.
You will get a file that you should save as *.tar. If you’ve downloaded to a Macintosh,
transfer the file to the server. If you are upgrading, you should mount a volume from
the server and move the file there. (Make sure your browser has not saved the
downloaded file as type TEXT.) If this is a new installation, you may want to use an ftp
client on the Macintosh to ftp (be sure to transfer in binary mode) the file to the server.
4. Once the file is on the server, you will need a place to extract it. Place it in /var/tmp or some
other place where you have enough free space. The tar file is not compressed, and will
take about the same amount of space extracted as it does whole.
5. Untar the file by becoming root in a shell window, and using this command:
# tar -xvf xinetsomething.tar

6
 Installing on SGI

where xinetsomething.tar is whatever you called the file when you copied it to the
machine.
6. Run the install script Xinet provides with the installation.
# ./installit
There is no need to reboot the server after the installation.

Installing on SGI From a local SGI CD ROM drive

1. If your CD ROM drive is mounted on the machine upon which you want to install
WebNative, use the Software Manager and the following procedure:
a. Double click on the CD icon. The Software Manager window will open.
b. Point the Software Manager to the dist directory and hit the customize installation
button.
c. Next, select WebNative and click Start.

2. You have completed installing WebNative after installwebnative has finished running.
As soon as installation is complete, your web browser should automatically launch,
pointing at the WebNative welcome.html which will provide information regarding
setting up WebNative.
If you can’t get Xinet software to install correctly, call Xinet Technical Support at the
numbers listed on page 5 or email help@xinet.com.

From a remote SGI workstation running IRIX 6.x

1. Use the Software Manager and point it at the remote CD ROM drive where you have
the WebNative CD mounted.
2. Point the Software Manager to the dist directory and hit the customize installation
button. Next, select WebNative and click Start.

As soon as installation is complete, your web browser should automatically launch

pointing at the WebNative welcome.html which will provide information regarding
setting up WebNative.

If you can’t get Xinet software to install correctly, call Xinet Technical Support at the
numbers listed on page 5 or email help@xinet.com.

From the web

If you are currently enrolled in the Xinet Maintenance and Support program, you may
download new software versions over the web. (Xinet products ship with a one-year mem-
bership.) To download software for all platforms:

7
 Chapter 1: Licensing, installation and client enhancements

1. Direct your browser to: http://www.xinet.com. Click on the Log in link and log in to
access product updates. If you do no know your login information, please contact your
Xinet Integrator or help@xinet.com.
2. Once you are logged in, click on Downloads, and then, Released Software.
3. Download the appropriate version of software for the operating system on your server.
Although an inappropriate version won’t install, you’ll waste downloading time if you
choose the wrong one.
You will get a file that you should save as *.tar. If you've downloaded to a Macintosh,
transfer the file to the server. If you are upgrading, you should mount a volume from
the server via the Chooser and move the file there. (Make sure your browser has not
saved the downloaded file as type TEXT.) If this is a new installation, you may want to
use an ftp client on the Macintosh to ftp (be sure to transfer in binary mode) the file to
the server.
4. Once the file is on the server, you will need a place to extract it. Place it in /var/tmp or some
other place where you have enough free space. The tar file is not compressed, and will
take about the same amount of space extracted as it does whole.
5. Untar the file by becoming root in a shell window, and using this command:
# tar -xvf xinetsomething.tar
where xinetsomething.tar is whatever you called the file when you copied it to
the machine.
6. Run the install script Xinet provides with the installation.
# ./installit

There is no need to reboot the server after the installation.

Installing on Mac OS X Installing WebNative on a Mac OS X system from CD

system
1. Put the FullPress/WebNative CD in the drive and double click on the icon after it
appears.
2. Find WebNative.pkg in the list and double click on it. The WebNative.pkg—Xinet dialog
box will open.
3. Click on the Install icon.
4. You do not need to set any installation options. Simply click on the Install button. A
status bar will show installation progress.
As soon as installation is complete, your web browser should automatically launch,
pointing at the WebNative welcome.html which will provide information regarding
setting up WebNative.
If you can’t get Xinet software to install correctly, call Xinet Technical Support at the
numbers listed on page 5 or email help@xinet.com.

8
 Installing on a Windows 2000 or Windows 2003 system

Installing from the web

If you are currently enrolled in the Xinet Maintenance and Support program, you may
download new software versions over the web. (Xinet products ship with a one-year mem-
bership.) To download software:

1. Direct your browser to: http://www.xinet.com. Click on the Log in link and log in to
access product updates. If you do no know your login information, please contact your
Xinet Integrator or help@xinet.com.
2. Once you are logged in, click on Downloads, and then, Released Software.
3. Download the appropriate version of software for the operating system on your server.
Although an inappropriate version won’t install, you’ll waste downloading time if you
choose the wrong one.
You will get a file that you should save as *.tar. If you've downloaded to a Macintosh,
transfer the file to the server. If you are upgrading, you should mount a volume from
the server and move the file there. (Make sure your browser has not saved the
downloaded file as type TEXT.) If this is a new installation, you may want to use an ftp
client on the Macintosh to ftp (be sure to transfer in binary mode) the file to the server.
4. Once the file is on the server, you can double-click on the package to extract it, if that
has not already happened automatically.
5. Install the package by double-clicking on the Xinetsoftware.XXX.pkg icon.
(where Xinetsoftware is the name of the product you download and XXX the version
number).
The installer program will unpack itself and install the software, after asking a few
questions, You may be asked to authenticate as an administrative user. FullPress file
and print services will be stopped during the installation. There is no need to reboot the
server after the installation.

Installing on a Windows Prerequisites

2000 or Windows 2003
system Before installing WebNative, make sure your system has:
• The latest version of FullPress available
• Apache WebServer 1.3.11 or later, installed as a “service.” See “Apache on Windows
2000 and Windows 2003” on page 28 for more information.

Installation from CD

1. Insert the FullPress/WebNative CD into the CD drive on your server. The installer will
launch automatically when you insert the CD. If it does not, click on the CDROM or
click on the WebNativ.exe file inside the \Windows folder.
2. Click on Install WebNative.

9
 Chapter 1: Licensing, installation and client enhancements

3. The Welcome dialog will open as shown below.

FIGURE 1. Welcome to WebNative

After reading the information there, proceed by clicking on the Next> button.
4. You must accept the terms of the Xinet license before continuing installation.
Afterwards, move on to the Choose Destination Location dialog.
5. WebNative software will be installed inside the same parent folder as FullPress. For
most installations, this will be C:\Program Files\Xinet\WebNative.

Click on the Next> button if that location works for your system.

If you want to install the software in another location, use the Browse... button to open
the Choose Folder dialog and establish a location for installation. Afterwards, return to
the Choose Destination Location dialog and click the Next> button.

If you are upgrading WebNative on top of an existing installation, the installation

program will install the upgrade in the same place as your original installation. You
can’t change the location without completely de-installing the software.

10
Installing on a Windows 2000 or Windows 2003 system

6. Users who want and are licensed for the added functionality of WebNative Venture
should select the WebNative Venture option, as shown below.

FIGURE 2. Installing WebNative Venture

7. Establish a password for the WebNative Administrator, nativeadmin, as shown in the

figure below.

FIGURE 3. Establishing a password for nativeadmin

8. If you have the MS World Wide Web Publishing Service (IIS) installed, it may produce
conflicts with the Apache Server. Xinet recommends that you disable IIS. The dialog
shown below gives you the opportunity.

11
 Chapter 1: Licensing, installation and client enhancements

FIGURE 4. Avoiding conflicts with IIS

9. The next dialog, shown below, gives you the chance to let the WebNative program
know about your mail server and who should be contacted when email is used in
conjunction with WebNative.

FIGURE 5. Using email in conjunction with WebNative

WebNative needs this information because some plugins and styles in WebNative can
be configured to send email in response to an action. For example, a user’s upload style
can be set to email which will prompt WebNative to send a message to the administrator
whenever the user uploads a file. This email is sent by WebNative via the mail server
with the user name you specify here.
If you do not have a server available or don’t plan to use email-enabled styles or
plugins, you may leave the server and address fields blank.
Note: Care must be taken when entering the server and email addresses, as the installer
will not verify that the addresses are valid. If you discover you’ve made an error, you
can rerun the installer to correct the server and user addresses.
Advanced users only:
If you are comfortable enough with the Windows OS, a more direct way exists for
changing the mail server and user settings. Go to the Bin directory of WebNative and
run the mailto.exe command in the following form:

mailto -install server_addr sender’s_addr

for example:
mailto -install smtp.xinet.com webnative@xinet.com
The settings for mail in WebNative are stored in the following location in the Registry.
HKEY_LOCAL_MACHINE:SOFTWARE:Xinet:WebNative:mailto

Plugins and styles can be made to send mail using the mailto.exe program found in the
WebNative\Bin directory. The command has the following form.
mailto filename -to recipient [-s subject -f sender]

12
Installing on a Windows 2000 or Windows 2003 system

10. WebNative program setup will proceed, displaying information about what is being
installed along with a progress bar. When complete, the Setup Complete dialog
appears, as shown below.

FIGURE 6. Finishing WebNative installation setup

11. Click on Finish to terminate the installation procedure.

Installation from the web

If you are currently enrolled in the Xinet Maintenance and Support program, you may
download new software versions over the web. (Xinet products ships with a one-year mem-
bership.) To download software:

1. Direct your browser to: http://www.xinet.com. Click on the Log in link and log in to
access product updates. If you do no know your login information, please contact your
Xinet Integrator or help@xinet.com.
2. Once you are logged in, click on Downloads, and then, Released Software.
3. Download the appropriate version of software for the operating system on your server.
Although an inappropriate version won’t install, you’ll waste downloading time if you
choose the wrong one.
You should get a file called Xinetsoftware.XXX.exe (where Xinetsoftware is
the name of the product you download and XXX the version number).
4. Login on your server as a user with “Administrative” privileges
5. Run the downloaded executable.
The installer program will unpack itself and install the software, after asking a few
questions. FullPress file and print services will be stopped during the installation. If the
server needs to be rebooted after the installation, the installer program will tell you.
When it is needed, it is not necessary to reboot immediately, but you will have to
reboot the server before starting Xinet services.

13
 Chapter 1: Licensing, installation and client enhancements

Note: Once FullPress is installed, a dtrebuild process will run which updates the
contents of the file ID database. Do not reboot your server until this process is finished
running. Follow the on-screen instructions in the FullPress installer for more
information.

Installing on a Linux Hardware requirements

system
Hardware requirements for FullPress® and WebNative® Venture installations on Linux serv-
ers are determined by software requirements. Please see Red Hat minimum hardware
requirements appropriate for your Red Hat Linux software version.

Xinet uses a USB dongle to license our products on this platform. Please be sure that your
Linux server has at least one free, functioning USB slot for this purpose.

Software requirements

Xinet software works on Red Hat 3, 4, and 5, either ES or AS/Base and Advanced, 32 and
64 bit. If you use a version of Red Hat 4 or 5, the software will run without AppleTalk.
Using AppleTalk is optional on Red Hat 3. If you plan to use Red Hat 5, please install the
additional libraries listed on page 14.

FullPress 15.03 and WebNative Venture 8.03 were tested on:

• Red Hat Enterprise Linux AS release 3 (Taroon Update 8), 32 bit, kernel module 2.4.21-
47.0.1.ELsmp,
• Red Hat Enterprise Linux ES release 4 (Nahant Update 4),32 bit, kernel module 2.6.9-
42.0.8.ELsmp
• Red Hat Enterprise Linux ES release 4 (Nahant Update 5),64 bit, kernel module 2.6.9-
55.ELsmp
• Red Hat Enterprise Linux Server Base release 5 (Tikanga), 32 bit, kernel module 2.6.18-
8.1.3.el5xen
• Red Hat Enterprise Linux Server Advanced release 5 (Tikanga), 64 bit, kernel module
2.6.18-8.1.3.el5

Additional libraries for Red Hat 5

If you plan to install Xinet products on a version of Red Hat 5, you must install older ver-
sions of Red Hat libraries before the Xinet software will work. Xinet suggests you install
the libraries before installing Xinet software. If you have a support contract with Red Hat,
you can easily download the libraries from the Red Hat web site.You need to install the fol-
lowing:
• compat-libstdc++-33-3.2.3-61.i386.rpm
• libXp-1.0.0-8.i386.rpm
• openmotif22-2.2.3-18.i386.rpm
• openssl097a-0.9.7a-9.i386.rpm

14
Installing on a Linux system

AppleTalk support on Red Hat 3

Support for a wide variety of hardware is not included by default with Red Hat Linux. To
add support for devices which Red Hat does not actively manage, maintain or support, addi-
tional drivers and protocol modules must be installed in the form of the kernel-unsupported
package. It is not a stand-alone kernel but rather an add-on for the running kernel. The ker-
nel-unsupported RPM can be installed either from CD or from Red Hat Network (RHN)
using up2date.

To install the add-on from the CD

1. Login as root
2. Load and mount CD 3 from your installation media.
3. Determine your kernel revision number by issuing the command:
Prompt> uname -r

Result (example): 2.4.21-27.ELsmp

4. Connect to the directory where the RPMs are located:
cd /mnt/cdrom/RedHat/RPMS
5. Execute the following command as the root user to install the kernel-unsupported
RPM:
rpm -ivh kernel-smp-unsupported-2.4.21-27.EL.i686.rpm
6. Once the RPM command completes, you can begin using the modules from the
unsupported kernel which are located in the directory:
/lib/modules/2.4.21-27.ELsmp/unsupported/

To install the add-on on a system that is registered with RHN

1. Execute the following command:

up2date kernel-smp-unsupported
2. Verify the installation:
# rpm -q kernel-smp-unsupported
kernel-smp-unsupported-2.4.27-27.EL

Once the up2date command completes, you can begin using the modules from the unsup-
ported kernel which are located in:
/lib/modules/2.4.21-27.ELsmp/unsupported/

Note: The up2date utility will download the most recent version of the kernel-unsupported
that is available for the registered channel.

15
 Chapter 1: Licensing, installation and client enhancements

Installing Xinet products

1. Confirm the USB dongle is plugged into the machine. The dongle has a green LED
light—please make sure it is lit.
2. Insert the FullPress/WebNative CD into the CD ROM drive
3. Working from the command line, change directory into the Linux directory on the CD:
cd /mnt/cdrom/Linux
4. Run the FullPress installer:
./installfullpress
5. Once the installer is finished, and the prompt reappears, install WebNative/WebNative
Venture, if you are also licensing that product:
./installwebnative
Red Hat 4 users, installing WebNative Venture, may encounter an installer error. If you
see an error like this:
usr/etc/venture/bin/mysqld: error while loading shared
libraries: libstdc++.so.5: cannot open shared object file: No
such file or directory
Installation of grant tables failed!
Then, install the following package from Red Hat:
compat-libstdc++-33-3.2.3-47.3.i386.rpm
Afterwards, reinstall WebNative Venture.
6. Restart AppleTalk:
/usr/etc/appletalk/atinit restart

Displaying the FullPress GUI

Once the FullPress installation is complete, the FullPress GUI will be launched. If Motif
libraries were not added during your installation of Red Hat Linux, you will see an error
about a missing library (libXm.so.3).

To resolve this issue, run up2date openmotif on the command line as root. Once Motif is
properly installed, the FullPress GUI will function as expected.

About WebNative client For WebNative client Macintoshes, Xinet developed a QuarkXPress 3–7 extension called
extensions and plug-ins WebNative® XT and an InDesign CS–CS 3 plug-in (Mac OS X only), called WebNative® ID,
for WebNative clients which optimize the sharing of documents when using WebNative. These programs have
been copied to your server during installation, giving you the option to distribute these
packages to WebNative clients. Here’s where to look:
UNIX server: /var/adm/webnative/
Windows server: C:\Program Files\Xinet\WebNative\Admin\

Mac OS X users should use the.XT.dmg package to install the extension and plug-in. Mac
OS 9 users should use the XT.sit package.

16
About WebNative client extensions and plug-ins for WebNative clients

Xinet includes information about the WebNative extensions and plug-ins its online help file
for QuarkXPress and InDesign previews, including a link so your clients can download the
packages for themselves. End users who upload files that have been saved on a workstation
without the WebNative extension or plug-in will also receive a message about using them
and a link. Although Xinet tries to automatically alert WebNative users about the extension
and plug-in, you may want to tell them about them beforehand, since the programs offer
users features that will enhance the way they view and work with documents and WebNa-
tive. Users can pick up the package for themselves by pointing their browsers to:
http:Your_WebNative_Server_Address/webnativedoc/doc/xt.html

where they will find the same link mentioned above.

Features

The plug-ins and extensions offer:

• An image “drag-and-drop” feature which makes using QuarkXPress in conjunction with
WebNative quicker, easier, and more error-free. Mac OS X users can also drag-and-drop
from InDesign CS–CS3. The extension allows users to drag and drop FPO images from
browsers logged into WebNative into QuarkXPress and InDesign picture boxes in docu-
ments on their local machines. “Dragging and dropping to QuarkXPress or InDesign
documents” on page 19 provides more information.
• A document preview feature, which automatically inserts previews into QuarkXPress
and InDesign documents that have been saved after WebNative XT and WebNative ID
have been installed. These previews are then used by WebNative and WebNative Ven-
ture to present thumbnail and larger previews of the document pages over the web.
Users don't have to download the document to look through it and get information about
the images used in it. InDesign CS2 and CD3 users can also export PDFs from InDesign
that go directly to the WebNative Server via a Xinet Uploader.1 (See page 23 for infor-
mation about Uploaders. The Xinet Client Guide presents more information for users.)
• In addition, Mac OS X users of Firefox who also use WebNative XT and WebNative ID
will find the WebNative Helper for Firefox useful. The Helper closes blank tabs and
windows that Firefox leaves open if either WebNative XT of WebNative ID has opened
them.

Notes about configuring the WebNative server for Drag and Drop

The WebNative Suite presents configuration options that allow you to optimize drag-and-
drop facilities for different environments. Typically, administrators should:
• Configure FullPress to Make EPS FPOs from all image formats on volumes from which
WebNative clients will be dragging images. (“About FPO Options” in the FullPress
Administrator Guide provides details).
• Make Large Web Previews that will be stored in the WebNative Venture database.
(“Enabling the database on volumes” beginning on page 88 provides details.)

1.Please note that the exportation of PDFs to Uploader will only work when the Uploader was created by a version of Uploader Manager 1.05 or later.

17
 Chapter 1: Licensing, installation and client enhancements

Configuring the server in this manner provides WebNative clients faster WebNative drag-
and-drop facilities. It also ensures that clipping paths will be stored in web previews.

As of WebNative 8.03/FullPress 15.03, the possibility exists to turn off FPO generation on
the server, and instead, rely upon on-the-fly Large Web Preview generation which will
occur whenever a WebNative client drags and drops an image. While you save some on
disk usage and processing time when the image first arrives on the server, the drag and drop
will not be as fast nor will clipping paths be preserved.

Configuring WebNative XT and WebNative ID on client systems

When a user who has installed WebNative XT or WebNative ID saves a file, the XTension
or plug-in places a “slug” inside the document. Depending on the settings the user has
established for the XTension or plug-in, the slug may contain two previews of each spread
in the document (a thumbnail and a 72 dpi preview) and information about every image
used in the file (name, directory ID, coordinates, etc.). The user controls which of these
pieces, if any, will be saved by the Preferences he or she establishes within the application.
These vary, depending whether the user is using QuarkXPress or InDesign.

Setting Preferences for WebNative XT (QuarkXPress)

Users will find the WebNative XT Preference dialog in the QuarkXPress Utilities menu.
Here is what each option controls:
• Off ensures that no additional information will be added to the document.
• No Previews ensures that no spread previews of any kind will not be added to the docu-
ment.
• Thumbnails Only ensures that thumbnail previews of spreads will be included in the
document.
• Full Previews ensures that full-sized 72 DPI previews of spreads will be added to the
document.
• Download/Link To prescribes whether you will link to an FPO or original file when
dragging and dropping images from your browser into new layouts.
• Save Image Info causes the position and status of images to be saved with the document.
• Picture Wrangler support controls whether WebNative will add information to the file
that Picture Wrangler can use to automatically relink images.

All of the options, with the exception of Off, will save extra image information with the file.
That means that it will take users a bit more time to save a documents when WebNative XT
is in use. Using the Off setting is the only way to avoid slower Save time; but, note the con-
sequence: Picture Wrangler will not be able to automatically locate images on the server for
that file.

Setting Preferences for WebNative ID (InDesign CS,CS2 and CS3)

There are two ways in which to establish the behavior of WebNative ID:
• Default application behavior
• Individual file behavior

18
About WebNative client extensions and plug-ins for WebNative clients

When in conflict, file behavior rules. No matter what settings one uses for WebNative ID,
WebNative ID will save extra image information when a user saves the file. That means that
it will take the user a bit more time to save a documents when it is in use. If performance
becomes an issue, one should use the InDesign>Configure Plug-Ins dialog to deactivate
WebNative ID.

SETTING WEBNATIVE ID DEFAULTS. Users set WebNative ID defaults using the InDe-
sign>Preferences>WebNative pull-down menu. These settings will be used automatically
when a user saves InDesign documents. Unless the user overrides these settings (see
below), they determine the kind of extra information that will be saved in files. Most sites
will want to establish the same WebNative Defaults on every workstation.

Here is what each option means:

• No Previews
Previews of spreads within the document will not be saved
• Thumbnails Only
WebNative ID will insert thumbnail previews of spreads
• Full Previews
WebNative ID will insert full-size 72 dpi previews of spreads
• Drag and Drop
Determines whether images a user drags from a browser into InDesign documents will
link to FPO or high-resolution images on the server. (The user must have the volume
where the image reside mounted on his or her desktop and have appropriate permissions
to download FPOs and/or high-resolution images before Drag and Drop will work.)
• Use Document Settings
This option will establish as default settings the same settings used in a currently open
InDesign document. If the user has more than one document open, it will use the set-
tings from the document that is on the top. (This option is only available when a user has
at least one InDesign document open.)

WEBNATIVE ID FILE SETTINGS. These settings, found in the Plug-Ins>WebNative dialog,

establish what information WebNative ID includes on a file-by-file basis. They override
Default Settings. They work in the same way as described above.

Dragging and dropping to QuarkXPress or InDesign documents

Exactly what happens when a user enables WebNative XT or WebNative ID and drags an
image from a web browser into a QuarkXPress or InDesign document depends on whether
or not the user has direct access to the FullPress volume where WebNative service origi-
nates. Most customers will be using WebNative through remote access, that is, without the
FullPress/WebNative volume mounted on their desktops.

WITHOUT A FULLPRESS VOLUME MOUNTED. Most commonly, WebNative XT or WebNa-

tive ID users will not be working on the same network where the images are stored. They
will use the web to download images, and will not be able to mount the parent volume
directly from the FullPress/WebNative server.

These users must already have permission to download FPOs. If they do, they may drag an
image from a WebNative window to a QuarkXPress or InDesign picture box. WebNative
XT or WebNative ID will instruct the browser to download the FPO of that image. After down-

19
 Chapter 1: Licensing, installation and client enhancements

loading is complete, the XTension or InDesign plug-in will decompress the image, and
place it into a folder called WebNative Downloads. This folder will appear in the default
download folder for the browser. In addition, the XTension or InDesign plug-in will embed
additional information about the FPO in the QuarkXPress or InDesign document so that
when the user uploads the document to the WebNative server, the service provider can use
Picture Wrangler to automatically relink the images that have been placed in it.

WITH A FULLPRESS VOLUME MOUNTED. Users who can actually mount the FullPress/Web-
Native volume where images reside may still choose to locate images and archives using
WebNative browsing and searching features. WebNative XT or WebNative ID works in a
slightly different manner than described above when a user has the volume mounted. If the
user drags an image from WebNative into a QuarkXPress or InDesign picture box when he
or she has the corresponding FullPress/WebNative volume mounted, WebNative XT or
WebNative ID will enable QuarkXPress or InDesign to automatically link to the FPO of the
image on the mounted volume.

About Microsoft Office Xinet WebNative Venture servers have been engineered “to talk” to OpenOffice.org soft-
previews ware (version 2.1 or later) which renders Microsoft Office documents into previews that can
then be stored in the WebNative Venture database. Besides WebNative Venture, you must
have OpenOffice.org (version 2.1or later) installed on your server before users can preview
Office files inside a WebNative browser. For your convenience, Xinet provides copies of the
appropriate version of OpenOffice.org 2.1 in the Downloads section of its web site,
www.xinet.com.

End users will not need to install any special software to preview Office documents. There
are, however, some issues for servers.

Server-side installation

Mac OS X servers

1. Check to see whether you have the X11.app installed on your server. If it’s not already
there, install it. Apple provides the program on the Mac OS X installation DVD as a
custom option. You can also download the software from the Apple web site.
2. Download the appropriate Mac OS X version of OpenOffice.org 2.1 from the Xinet
web site
3. Open the .dmg file and double click on the OpenOffice.org2.1 icon to begin installation.
A wizard will guide you through the rest of the process, installing the software in the /
Applications directory.
4. If you have installed OpenOffice.org before installing WebNative Venture, you are
ready to install WebNative Venture now. If the opposite is true, start the following
program from the command line:
/usr/etc/venture/bin/openoffice.org2pdfpdfsetup.sh

20
About Microsoft Office previews

Linux servers

1. Check to see that /usr/X11R6/bin/Xvfb exists on your server. (It isn’t, by default,
installed on all Linux servers.) If it is not there, use the Red Hat installation disk to
install it, as follows:
rpm -ihv xorg-x11-Xvfb-xxx.rpm
(where xxx is the specific version number based on the Red Hat distribution and
architecture you are using).
2. Install OpenOffice.org version 2.1 by first downloading
OOo_2.0.4_LinuxIntel_install.tar from the Xinet web site.
3. Untar the download as follows:
tar -xvf OOo_2.1_LinuxIntel_install.tar
This will create a directory in /opt called something similar to:
OOE680_m6_native_packed-1_en-US.9095
4. A subdirectory resides inside this directory called RPMS. Go into this subdirectory and
install the OpenOffice.org packages using the following command:
rpm -i *.rpm
5. If you have installed OpenOffice.org before installing WebNative Venture, you are
ready to install WebNative Venture now. If the opposite is true, start the following
program from the command line:
/usr/etc/venture/bin/openoffice.org2pdfsetup.sh

Solaris on Sparc: Solaris 9 and later

1. Download OpenOffice.org for Solaris from the Xinet web site. You will end up with the file:
OOo_2.1.0_SolarisSparc_install.tar.gz
2. Expand the file using gunzip(1):
gunzip ./OOo_2.1.0_SolarisSparc_install.tar.gz
3. Untar the file as follows:
tar -xvf OOo_2.1.0_SolarisSparc_install.tar

This will create a directory within /opt with a name similar to:
OOE680_m6_native_packed-1_en-US.9095
4. Navigate to a subdirectory within this directory called packages, and then run the
following command:
pkgadd -d .
Answer yes to any questions.
5. If you have installed OpenOffice.org before installing WebNative Venture, you are
ready to install WebNative Venture now. If the opposite is true, start the following
program from the command line:
/usr/etc/venture/bin/openoffice.org2pdfsetup.sh

21
 Chapter 1: Licensing, installation and client enhancements

Windows servers

1. Download the zipped version of OpenOffice.org for Windows from the Xinet web site.
2. Double click to unzip the file and open the OpenOffice.org installer, which will lead
you through the installation process.
3. If you have installed OpenOffice.org before installing WebNative Venture, you are
ready to install WebNative Venture now. If the opposite is true, run the following
program from the command line:
C:\Program Files\Xinet\Venture\bin\openoffice.org2pdfsetup.bat

Configuration

To obtain WebNative previews for Office documents, the web volume you are using must
be WebNative-Venture enabled. “Enabling the database on volumes” on page 88 provides
information about that. You will also need to enable the option, Store Multi-page PDF pre-
views, as well as having Store Small Web Preview, and Store Large Web Preview enabled,
all described on page 89.

OpenOffice.org and fonts on UNIX servers

As OpenOffice.org begins rendering files, it needs to have access to appropriate TrueType

or Type 1 fonts in the correct repository; otherwise, it can not render documents accurately.
On UNIX systems some care needs to be taken to ensure that the appropriate fonts reside in
the appropriate location.

For more information about fonts and OpenOffice.org, refer to:

http://wiki.services.openoffice.org/wiki/Font-FAQ
http://www.openoffice.org/FAQs/fontguide.html

Mac OS X servers

When you install/upgrade WebNative Venture on a Mac OS X server, it will take the fonts
in /System/Library/Fonts and /Library/Fonts, convert them into appropriate TrueType fonts
using the OpenOffice.org fondu utility, and then install them in the OpenOffice.org font
space.

If subsequently, you install additional fonts on your Mac OS X system, or if you’ve

installed WebNative Venture before OpenOffice.org 2.1, you should run the Xinet
/usr/etc/venture/bin/openoffice.org2pdfsetup.sh program (without any arguments) to con-
vert and copy new fonts to the appropriate place for OpenOffice.org. Please keep in mind
that any new fonts need to be placed in either /System/Library/Fonts or /Library/Fonts for
openoffice.org2pdfsetup.sh to work.

Linux and Solaris servers

When you install/upgrade WebNative Venture on a Linux or Solaris server, it will copy any
X11 fonts already on the system to the appropriate OpenOffice.org repository, i.e., /opt/
openoffice.org2.1/share/fonts/truetype.

22
 Other client production extensions and plug-ins

If you would like additional fonts on your system, or if you’ve installed WebNative Venture
before OpenOffice.org 2.1, you can copy the fonts by hand into /opt/openofficeorg2.1/share/
fonts/truetype or run the OpenOffice.org utility, spadmin, which resides in /opt/openof-
fice.org2.1/program. The spadmin utility provides a GUI for adding fonts.

Other client production Xinet also distributes FullPress plug-ins and extensions that interact with WebNative. They
extensions and plug-ins are not distributed with the WebNative plug-ins and extensions discussed on page 16–
page 20 because their use depends upon direct access to FullPress volumes to which every
WebNative user will not have access. Instruct any of your users who need these packages to
install them using the Macfiles FullPress volume. The FullPress Administration Guide and
the Xinet Client Guide both contain more information. Following subsections provide brief
descriptions of these packages.

Interactive PDF: Annotator XT for QuarkXPress and Annotator Plug-in for InDesign
CS and CS2

Annotator XT and the Annotator Plug-in work in conjunction with FullPress print queues
and enable two functions:
• Users can create PDFs that contain interactive links to images that reside on the Full-
Press/WebNative server. Clicking on an image in a PDF that has been generated by an
appropriate FullPress queue will, by default, bring up the image in the user’s WebNative
browser.
• Annotator XT and the Annotator Plug-in also provide a mechanism that directs print
output to a folder relative to the original file location.

Keep in mind that these features require that your server is appropriately configured and
that the plug-in and extension have been installed on each workstation. The plug-in and
extension will only work with InDesign CS and later and QuarkXPress 3–7. For full func-
tionality, they also require that WebNative Venture is running on your server. Refer to the
Xinet Client Guide if you would like to read more about Annotator XT and the Annotator
Plug-in.

Uploader Manager

Xinet Uploaders provide an efficient drag-and drop mechanism for uploading files to a
WebNative Venture or WebNative Portal server. Xinet Uploader also allows users to associ-
ate metadata with uploaded files. Most WebNative administrators will want to use the
Uploader Manager so that they can distribute preconfigured Xinet Uploaders to end users.

The Installer places a copy of the Uploader Manager inside the Macintosh’s Applications/
Xinet Software folder. A Configuration Creation Wizard guides the configuration process.
To get started, click the New button, and follow the instructions. To successfully configure a
Xinet Uploader, you will need to know:
• The URL of the WebNative or WebNative Portal server
• The user’s WebNative login and password
• Any HTTP proxy information required for the user’s computer to use HTTP or HTTPS
• SMTP server information from the client, if you enable email reports.

23
 Chapter 1: Licensing, installation and client enhancements

Please note that you must also configure additional WebNative Venture userperm settings
before anyone can associate metadata with uploaded files. “Adding permission sets” on
page 131 provides more information.

FullPress Versioning plug-ins for Photoshop, Illustrator, and InDesign with WebNa-
tive Version Management

There are two components to the Xinet’s version management:

• The FullPress® Versioning plug-ins for Adobe Photoshop, Illustrator and InDesign
automatically create and save versions of files, enforcing naming conventions for the
backups as they do so. The plug-ins also offers a mechanism for reviewing and managing
versions.
• The WebNative® Version Management component allows remote viewers to see the
various versions of files in a web browser, select a new “current” version for production
use, delete versions, and download versions.

Refer to “Modifying a volume’s AppleShare options” in the FullPress Administration

Guide for more information about the Versioning plug-ins. Page 40 of this manual provides
more information about WebNative Version Management.

Xinet Contextual Menus

XinetCM is a contextual menu extension, installed on Macintoshes using the FullPress

Installer, that offers shortcuts for working with FullPress and WebNative when working
against a FullPress server. It allows users to reveal and open items in the Finder directly
from a WebNative browser, as well as to navigate between FPO and High-res views in the
Finder.

Removing WebNative On UNIX systems

from the server
From IRIX systems:

Use either the swmgr(1M) GUI or the versions(1M) utility to remove WebNative from your
system. You must run these as root in order for the package to be smoothly de-installed.

If you use the versions(1M) utility, invoke it as follows:

# versions remove webnative

From Solaris systems:

Use either the swmtool(1M) GUI or the pkgrm(1M) utility to remove WebNative from your
system. You must run these as root in order for the package to be smoothly de-installed.

If you use pkgrm(1M), remove WebNative like this:

# pkgrm webnative

24
 Removing WebNative from the server

From a Mac OS X system:

Run the following commands in a Terminal window:

Mac OS X # /usr/etc/venture/bin/dbmgr -shutdown

Server # /usr/etc/venture/bin/dblogd -k
# rm -r /usr/etc/webnative
# rm -r /usr/etc/venture
# rm -r /var/adm/webnative
# rm -r /Library/Receipts/WebNative.pkg

From a Linux system:

Xinet provides a script for removing FullPress, WebNative, and WebNative Venture from a
system. The Linux uninstall script performs a clean removal of Xinet products. This means
that it will remove all directories related to FullPress, WebNative and WebNative Venture,
including /var/adm/appletalk and /var/adm/webnative. If you wish to preserve data in any
of these directories, please make copies using
cp -pR before proceeding.

This uninstall script is located inside the install package. If you no longer have that pack-
age, obtain a new one from the Xinet web site, www.xinet.com. Once the script is available,
run the following command from the directory where the package is located:

# ./uninstall

This script will stop all FullPress and WebNative Venture services and remove all Xinet-
related directories.

WINDOWS On Windows systems

1. Open the Control Panel, then the Add/Remove Programs dialog.

2. Select Xinet WebNative, then click the Add/Remove... button.
3. Select Change/Remove, and then answer Yes to confirm your selection.
This removes the Xinet-licensed software, but be aware that the users’ files,
configuration files and the WebNative Venture data tables will still be on your system.

25
 Chapter 1: Licensing, installation and client enhancements

26
 The configure.apache script

Chapter 2

Selecting, installing, and configuring a web server

WebNative is not itself a web server. Instead, it relies on an existing web server to provide
HTTP access and security control. WebNative can be configured to run with any web server
that supports CGI programs, security, and security realms. However, if you use the Apache
web server, where WebNative can control user lists, WebNative configuration is essentially
automatic. If you are an experienced web administrator, you may choose to run a non-sup-
ported web server. If so, skip to “Configuring a non-supported web server” on page 28 to
find out what you need to do. Otherwise, find the correct section below for the platform you
are using for information about using the Apache server.

Xinet TechNote 114: Apache Webserver FAQ available at www.xinet.com provides more
information.

The configure.apache Apache needs to be configured appropriately to work with WebNative. Xinet provides the
script configure.apache script to take care of this. Whether or not/how you interact with this script
may vary, depending on your operating system and local details. The OS-specific details
that follow this section provide more information about the script.

For some operating systems, a version of Apache comes pre-installed. The config-
ure.apache script will look for it when attempting to configure your web server. If the script
doesn’t find Apache where it expects it to be, it will prompt you for the location where
Apache has been installed. When prompting, configure.apache will offer a guess if it finds
something in the file system that looks like an Apache installation. You can either confirm
that guess or override it by typing a new location.

A -nodefault switch or flag exists for configure.apache which causes configure.apache to

completely ignore OS-specific, pre-existing Apache installations and to always prompt the
user for the location of the version of Apache to use. This switch exists for those who don’t
want to use their OS-specific default installation of Apache, but still wanted to use config-
ure.apache. Without the -nodefault switch, configure.apache would never ask for a different
Apache installation and would, thus, configure the OS-specific Apache installation. If
appropriate, use the switch as follows:

# ./configure.apache -nodefault

Then supply the location of the Apache installation when prompted. You may run the con-
figure.apache script at any time it’s warranted.

Apache on Solaris Download the latest version of Apache from www.apache.org. While source code is avail-
able, is far easier to get a complete binary release which is available from www.apache.org/
dist/binaries/solaris. Once you have installed Apache, follow these steps:

1. # cd /usr/etc/webnative
2. # ./configure.apache

27
 Chapter 2: Selecting, installing, and configuring a web server

The script will ask you where you installed Apache. After you supply that information, it
will configure Apache and start a browser pointing to WebNative. Authenticate as the user
nativeadmin with the root password.

Apache on IRIX Download the latest version of Apache from www.apache.org. While source code is avail-
able, it is far easier to get a complete binary release. These are available from
www.apache.org/dist/binaries/irix. Once you have installed Apache, follow these steps:

1. # cd /usr/etc/webnative
2. # ./configure.apache

The script will ask you where you installed Apache. After you supply that information, it
will configure Apache and start a browser pointing to WebNative. Authenticate as the user
nativeadmin with the root password.

Apache on Mac OS X A version of the Apache server ships with Mac OS X Server. When you install Mac OS X
Server, you should choose to install the web server. After installing WebNative.pkg,
WebNative should be ready to use. Point a browser at the machine by entering the hostname
or IP address, then authenticate as the user nativeadmin. Initially, the password will be
either the Admin password or blank (in which case, nothing needs to be typed in the pass-
word field). If the password was blank, be sure after you have authenticated, to change the
password for nativeadmin to a real password.

Apache on Linux A version of the Apache server ships with Linux Red Hat. When you install Red Hat soft-
ware, you should choose to install the web server. When you run the installwebnative script,
you will be prompted to specify the location where Apache was installed. After you supply
that information, the script will configure Apache and start a browser pointing to WebNa-
tive. Authenticate as the user nativeadmin with the root password.

Point a browser at the machine by entering the hostname or IP address, then authenticate as
the user nativeadmin with the system’s root password.

Apache on Windows If you don’t already have a copy, you can pick one up at http://www.apache.org/dist/bina-
2000 and Windows 2003 ries/win. You cannot install WebNative until you have installed Apache. After installing
Apache, WebNative should be ready to use with the server. Point a browser at the machine
by entering the hostname or IP address, then authenticate as the user nativeadmin with the
password you established during WebNative installation.

Configuring a non- This section is provided for experienced web server administrators who want to configure a
supported web server server that is not “supported.” If you do not understand the terminology in this section, we
suggest you choose one of the “supported” servers for your platform.

WebNative requires the following server attributes to function:

• The URL /webnative must reference /usr/etc/webnative on Unix systems or on Windows
systems C:\Program Files\Xinet\WebNative\Bin. The server should allow CGIs (and
only CGIs) to run from this directory.

28
 Setting up directory services for WebNative

• The URL /webnativedoc must reference /var/adm/webnative on Unix systems or C:\Pro-

gram Files\Xinet\WebNative\Admin on Windows systems. The server should allow only
document access (no CGIs) from this directory, and it should not allow users to index
the directory.
• Both /webnative and /webnativedoc should have user access control, and they should
use the authentication realm WebNative. It is up to you whether you share a user data-
base with the rest of your server or maintain a separate one for
WebNative.
• You need to create any WebNative users you want. You at least need to create a
nativeadmin user to allow WebNative administration to work.

After setting up this configuration and restarting your server, you will need to place a link to
/webnative/listdir somewhere on your site. (If you want, you can copy the WebNative logo
from /var/adm/webnative/images/logo.gif for use with the link.) Authenticate as nativead-
min and follow the configuration steps in the next chapter. Note, that since WebNative is
unaware of your user list, anywhere the documentation shows a user pop-up, you will see a
type-in field where you must specify the user. If you want to add, remove, or change the
password of a user, you must do it through your server’s administrative interface rather than
through the WebNative interface.

Setting up directory If you are interested in setting up directory services to work with your WebNative Apache
services for WebNative server, please refer to Xinet TechNote 218, available in the Help section at www.xinet.com.

29
 Chapter 2: Selecting, installing, and configuring a web server

30
 Chapter 3

WebNative configuration
Before you and your customers can begin using WebNative, you have to set up your web
server to work with WebNative, and then set up WebNative so that it understands how you
want each of your customers to interact with it. This chapter deals with the first task. The
next chapter explains how to administer WebNative for your customers by using WebNa-
tive’s administrative GUI.

If you have not already done so, add a new FullPress volume which supports WebNative, or
modify existing ones to support WebNative. For full details about adding a FullPress vol-
ume, refer to “Creating new shared volumes” on page 142 of the FullPress Administration
Guide. Once you’ve done this, you will have the option of making any files in the volume
available to customers over the Web:

1. Click the Volume Management button in the FullPress GUI.

2. Use the New Volume button and establish a volume, or select an existing volume and
the Modify button.
3. Turn on the Support Webnative on this volume option by clicking the button next to it:

Support WebNative option

FIGURE 7. Enabling WebNative support in FullPress

31
 Chapter 3: WebNative configuration

4. [optional] Establish watermarks if you would like them to appear in web-ready

versions of images. The use of watermarks can help protect the images from
unauthorized use. Refer to “Watermarks” in the “FullPress AppleShare volume
management” chapter in the FullPress Administration Guide for further details.
5. [optional] Set Web view Access restrictions. These options allow the system
administrator to manage who will have access to the web-view of the volume via AFP.
See the chapter titled “Security settings” in the FullPress Administration Guide for
details about access control lists.
6. Click on the Save button to close the dialog box.
If you want to use the default settings for web preview generation, and you don’t want
to generate previews for any pre-existing images stored on the volume, you are done.
(At this point, the software generates web previews for any new image added to the
volume, but will not generate them for pre-existing images. There’s an option
described below for generating web previews for all images on the volume.)
7. If you want to fine tune web preview generation or generate new previews for all
existing images on the volume, click on the WEB Options button at the bottom of the
AppleShare Volume Management dialog box. The Options for making WEB FPOs
dialog box will open.
8. Some administrators, mainly for performance issues, may want to keep FullPress from
making web-ready previews of certain files. Three options exist:
– Don’t make WEB previews for EPS files
– Don’t make WEB previews for PDF files
– Make GIF-format WEB previews of masked or clipped images
There option, Make GIF-format WEB previews of masked or clipped images, exists for
situations where it is important that previews show masks and clippings paths (not
possible with JPEG previews). Keep in mind, however, that except for masks and
clipping paths, GIF previews will not be as sharp as JPEG ones.
9. If you want to limit the pixel dimensions of WEB FPOs, check the box for this option
and include a value in the type-in box. In some instances the value you set here may
override the resolution for WEB FPOs (set below). That’s because, even at the selected
resolution, some images can be too large to fit in a web browser window. This option
limits an image to a specified number of pixels.
10. You may also limit image resolution by DPI or DPCM. By default, WebNative sets this
value to 72 DPI. You may, however, type in other values.
11. If you would like to update already existing WEB FPOs with these parameters click on
the Update WEB FPOs button. You’ll be asked to confirm your choice before it
actually takes place.
12. If you want to preserve changes you’ve made, click on the Save button. Otherwise,
click on the Cancel button to dismiss the dialog box.

32
 Overview

Chapter 4

General WebNative administration

Overview You'll use the WebNative administration interface to configure volumes on your web site
for customers, or in other words, to give your customers access to their images on the server
via the Web. At this point, you should have already established FullPress volumes which
support WebNative on the server, as described in Step 3. on page 31.

Basic administration Most basic administration is carried out using the WebNative administrative GUI. You must
steps be authenticated to the web server with administrative privileges to use it. The directions in
this section cover basic administrative steps including:
• Authenticating as the administrator
• Adding users
• Specifying which volumes users will see
• Specifying how those volumes will function (configuring plugins)
• Modifying or deleting volumes

Later sections cover more advanced customization. Each WebNative GUI displays a Help
button. If you need definitions for any of the terms used or explanations about what the but-
tons on the GUI do, press the Help button. The following steps describe how to set up Web-
Native to give access to a remote user. You can complete each step for many users and then
move on, or repeat the process for each new user you add. We suggest that you go through
the entire process at least once, establishing access for a single user, before taking the batch
approach.

Authenticating as the 1. From your web browser, connect to the top level of the server. If you see the
administrator WebNative logo, click on it. Otherwise, append the path /webnative/userperms to the
URL path.
2. In either case, you will be asked to authenticate yourself. Use nativeadmin as the
user name. If you are using FastTrack or Apache on a Solaris, irix, or Linux system,
use your server’s root password as the password; on Windows systems, use the
password you established during WebNative installation; on Mac OS X systems,
initially, the password can be either the Admin password or blank (in which case,
nothing needs to be typed in the password field). If the password is blank, be sure after
you have authenticated, to change the password for nativeadmin to a real password.

FIGURE 8. Logging in as nativeadmin

33
 Chapter 4: General WebNative administration

This will open the a dialog box similar to the one below, showing a summary of
attributes for the last user or group (if any exist) that was established on the server:

Two-tiered pop-up
selection system

FIGURE 9. The nativeadmin administration GUI

3. Use the tabs across the top to look at different aspects of WebNative administration.
Please note that the tabs that pertain to WebNative Venture will not function if you
haven’t licensed and installed that component.
4. You may, if you wish, change the nativeadmin password at this point. Refer to
“Changing the nativeadmin password” on page 55 if you would like more information.

Making GUI selections Notice the two-tiered pop-up menu in Figure 9. You will encounter this two-tiered pop-up
system whenever a list grows longer than 29 entries. Its purpose is to speed up your selec-
tion process, saving you from having to scroll through too many names.

The upper pop-up specifies an alphanumeric range, in this particular case, the users between
48960 and carl2. The lower pop-up specifies the particular user, arabia, within that range.
You can see in Figure 10 the choices of users within another range, the Marge–wnvtester
range, and in Figure 11, all the other possible ranges. Also note that groups come after the
list of users.

FIGURE 10. Users within the alphabetic range

34
 User summary

FIGURE 11. Other possible ranges

User summary WebNative administrators will find it handy to quickly display information about a user’s
WebNative account. The Summary subtab under the Users tab provides information about
numerous settings for each user and also provides a convenient way to automatically navi-
gate to the correct subtab of the nativeadmin GUI to change settings.

To display a user summary and to edit values:

1. Select the Users/Summary subtab if it is not already selected.

2. Use the two-tiered Username selection pop-ups to select the user or group in which
you are interested. You should see something similar to the display in Figure 12.

Clicking one of the Edit links will

automatically open the appropriate
subtab for you to change WebNative
attributes for the selected user.

FIGURE 12. Displaying a summary of a user’s WebNative profile

3. To edit any attribute, click the Edit button associated with it. You will taken to the
appropriate page to change those parameters for the selected user.

Adding users For most administrators, one of the first step will be to create WebNative user accounts on
the server. To do this, click the User tab at the top of the GUI if it’s not already selected,
then the link, New User, to open the New User subpanel.

This allows you to provide access to a user who doesn't already have access to WebNative
volumes. To give a new user access, you'll need to:

35
 Chapter 4: General WebNative administration

1. Supply the user's name and a password, then verify the password by re-entering it in
the Password (again) field.

FIGURE 13. Adding new users

2. If you would like to allow the user to change his or her password, enable that option.
3. Add the user to groups, if appropriate. Or, use the Copy User pop-up menu to copy
group memberships from another user. Refer to “Creating and editing groups” on
page 53 for information about setting up groups.
If you add the user to more than one group, as the example in Figure 13 shows, also
choose a Primary Group. This establishes how WebNative will respond when there are
conflicts between group settings.
4. If you want a person notified when this user uploads files to the server, enter the
recipient’s email address.
5. You may optionally prevent or allow access to WebNative from a remote machine. This
means you can limit some users so they only have access when they are on-site, but
give others access from local and remote sites.
To set access, use the pop-up Access Control List. The items you see only include
addresses. No ACLs for individual users show up. That’s because, at the time the user
first makes contact with the WebNative server, he or she hasn't yet logged in.
Therefore, only the user’s address, not his or her login, will be known
The default choice None gives the user access from any location. Use the FullPress
GUI to add additional ACLs to your pop-up list.
6. Click on the Add User button.

New users will be added to the WebNative user database only; they are not given any
user access to the server itself.

Your customers will need to be given their user names and passwords before they can
have access to the volumes on your web site.

36
 Changing attributes for existing users

Changing attributes for To modify an existing user:

existing users
1. Click on the link to the Users/Edit subpanel. You’ll see something similar to Figure 14
below:

FIGURE 14. Changing attributes for an existing user

2. Select a user to modify with the two-tiered Username menu.

3. If you change the password, you must verify it by retyping it in the Password (again)
box. You may also allow the user to change his or her password by checking the box
next to that option.
4. If you’ve established groups, you may include this individual.
5. You may add an Upload email address if you want to have a staff member notified
when this particular user uploads anything to the WebNative server.
6. You may optionally prevent or allow access to WebNative from a remote machine. This
means you can limit some users so they only have access when they are on-site, but
give others access from local and remote sites.
To set access, use the pop-up Access Control List. The items you see only include
addresses. ACLs that contain users will not show up because WebNative users are not
considered “local” users.
The default choice “None” gives the user access from any location. Use the FullPress
GUI to add additional ACLs to your pop-up list.
7. When you are satisfied with your changes, click the Submit button.

37
 Chapter 4: General WebNative administration

Giving users access to To establish the folders or subdirectories of a volume to which a new user has access:
volumes
1. Click on the Volumes tab, then select the user name in the Volumes for pop-up menu.
2. Click on the Add Volume button and fill-in the information by using popup lists, check
boxes or typing, as described below.

FIGURE 15. Configuring a user’s permissions for WebNative access to a volume

• Owner: This two-tiered pop-up list allows you to choose the customer or user who
has access to the volume. If you do not see the user name you want in the list, click
Dismiss, then establish a new user by clicking the Users tab, then New User.
• Web volume: This pop-up list allows you to choose the web volume to which
you're giving the user access. The pop-up list you see here contains all the volumes
on the server for which WebNative has been enabled. These volumes, presumably,
are where you are keeping customers’ or staff files. It’s likely that you have orga-
nized volumes so that files reside in distinct subdirectories, and you can constrain
access to a given subdirectory if you want.

Web volumes are originally established through the FullPress AppleShare Server
Setup GUI, on the server. If you don't find the volume you’re looking for in the
pop-up list of web volumes, you need to return to this FullPress Administrative
GUI and enable WebNative for your volume.
• Folder: This is optional. In some cases you may want to limit a customer’s access
to a subdirectory or folder within a volume. You can do so by using the pop-up list.
You may go as deep as you want, for example, a subdirectory within a subdirec-
tory. The GUI displays the current path beneath the pop-up list.
• User Volume Name: What you type here establishes the name of the volume or
subdirectory that the user will see on the web when he or she goes to your web site.
3. Using the bottom portion of the GUI, establish permissions for WebNative volume
access. What you see as default settings depends on previously-established volume
permissions. WebNative tries to make setting volume permissions as easy as possible
by remembering earlier choices and applying rules in the following order:

38
Giving users access to volumes

a. If they exist, WebNative will use the most-recently-established permissions for a

selected user or group.
b. If it is a user or group without previously-established permissions,
WebNative will copy the settings that were most-recently assigned to
a user or group.
c. If volume permissions have never been configured on the server, WebNative will
provide its own default settings.
d. You may, of course, override default settings.
The permission settings fall into six categories which include:
Image Previews
• Small Preview: This determines whether or not users will see small previews of
images. Small previews are, at most, 112 pixels in either horizontal or vertical ori-
entation. These are the previews which, by default, users see in WebNative's Short
View. Without Small Previews, images must be identified by custom-icon previews
or possibly 72-DPI previews.
• 72 DPI Preview: This determines whether you allow users to view “large” pre-
views of images. The 72-DPI preview is useful for customers who wish to down-
load Web-ready images for use on their own web sites. You may want to turn this
feature off if you wish to charge customers for Web-ready images.
File Views
• No icon view: This determines whether or not users, when browsing, can view
files in WebNative using the icon format. Icon View shows files and folders
together, with a Macintosh-style icon displayed for each item. For images, a cus-
tom icon will be generated from the image data. For non-images, the icon will be
the icon of the application that created the document. Clicking on an icon will
bring up more information about the file. Clicking on a folder will display the con-
tents of that folder in the browser.
• No short view: This determines whether or not users, when browsing, can view
files in WebNative using the Short View format. In the short view, all subfolders of
the current folder will be displayed first, with a icon next to them. Clicking on the
folder name will display the contents of that folder in the browser. Following the
folder listing is a table of the files in the folder. The file’s name appears first in each
table entry. If available, there will be a 112x112 pixel preview. If not, the icon for
the application that created the file will be displayed. Below the image, there will
be a set of icons representing actions described above. Which icons are displayed
will depend on the permissions given to the user who is connected.
• No long view: This determines whether or not users, when browsing, can view
files in WebNative using the Long View format. In the Long View, the display will
start with a listing of folders preceded by the icon. Following that will be a
detailed listing of each image, including a 112x112 pixel preview. The contents of
the listing are identical to the information presented in the information window,
with the exception that you will not be able to change keywords. You may also add
items to your Shopping Basket when viewing files this way.

39
 Chapter 4: General WebNative administration

Default View
• Icon view default: This setting means that the WebNative user will see informa-
tion in the Icon View format, by default, when beginning a
WebNative session.
• Short view default: This setting means that the WebNative user will see informa-
tion in the Short View format, by default, when beginning a
WebNative session.
• Long view default: This setting means that the WebNative user will see informa-
tion in the Long View format, by default, when beginning a WebNative session.
File Information
• Show Dates: This determines whether or not information appears about the time
when the image was last accessed, last modified, and last created.
• Show Comments: This determines whether or not users will see the Comments
field in image information windows and WebNative's Long View mode. All Web-
Native users will see Comments, unless you choose to suppress them.
• Edit Comments: This determines whether you will allow WebNative users to add
to, or change, the information which appears in the Comments field of the informa-
tion window, in Long View, and in the -I dialog box.
• Edit Data Fields: This determines whether or not users can edit WebNative Ven-
ture data fields.
• Show FPO Info: By default, each FullPress FPO includes information about itself
and its corresponding high-resolution image. You may wish to suppress this infor-
mation if customers are not interested in FPOs or you do not want to reveal infor-
mation about the high-resolution images.
• Show History: This option only works in conjunction with WebNative Venture.
Turn on this option if you want a WebNative Venture user to be able to view a
detailed history of what has happened to a particular file on the server.
When the option is “on,” a Detailed History button appears in WebNative
Information windows. Clicking that button displays the detailed history of the
particular file, including information about the actions performed on it, the dates
when they occurred, the users who performed them and the users’ IP addresses.
These icons appear when • Show Versions: This WebNative version management options works in conjunc-
you turn on the Show tion with the FullPress Versioning plug-in for Photoshop, the FullPress Versioning
Versions option: plug-in for Illustrator, and the FullPress Versioning plug-in for InDesign. It allows
remote viewers to see the various versions of files in a web browser, change which
of those versions is considered to be the “current” version for production use,
The Show Versions icon delete versions, and download versions.
Be sure that you have also turned on File Management. Show Versions will not
work, otherwise. Please also note that you must be running WebNative Venture for
The Make Current Working this feature to work with archived versions of files.
Version icon
Please note: If you have changed the default name of the Versions folder (see
“Setting up FullPress Versioning for Photoshop, Illustrator and InDesign” in the
FullPress Administration Guide) you must also make sure that WebNative or
WebNative Venture knows about the change. On UNIX systems, create a file inside
/var/adm/webnative, called versions.conf. On Windows systems, create a file
inside C:\Program Files\Xinet\WebNative called versions.conf. Inside the

40
 Giving users access to volumes

versions.conf file, insert a single line of text consisting of the new Version Folder
Name, for example, our_versions or hans.

Figure 16 shows the version management interface:

FIGURE 16. The version management interface

• Show Linked Files: The linked files viewer allows WebNative users to find and
see previews of all the documents in which a selected image has been used, even
When you turn on Show when that file has been archived. It provides a visual summary about link informa-
Linked Files, the Linked tion stored in the database.
File Viewer icon
appears in File Info WebNative Venture must be installed on the server and enabled on the volume
dialogs. where the images of interest reside.The linked files viewer operates on
QuarkXPress files (Version 3 or later) which have been saved with the WebNative
XT extension enabled, on InDesign files (CS or later) saved with the WebNative
plug-in enabled, and on PDFs that have been generated with the Annotator
(Interactive PDF) plug-in in place or that have been produced using FullPress so
that they have OPI comments that can be read by WebNative Venture.

41
 Chapter 4: General WebNative administration

File Permissions
These check boxes allow you to give WebNative users access to and/or permission to
manipulate files on the server. Permissions for downloading files have been broken out
in a separate pop-up list, that appears just below these options:
• Shopping basket: This determines whether customers can use the “shopping bas-
ket” feature for batch downloading of files. When customers use the shopping bas-
ket to transfer images, the collection of images will be compressed before transfer
and automatically decompressed when they reach the customer’s site. This greatly
increases the speed of transfer. If the shopping basket feature is enabled, a basket
appears when customers are browsing. Customers use the basket to add images or
documents to their baskets.
• Custom Image Order: Turning on this feature allows customers to download
images scaled to the size they need for a particular purpose. “Viewing WebNative
access logs” on page 55 provides information about looking at logs of download
activity.
• Allow Uploads: This determines whether or not a customer can use WebNative to
place files on the service provider’s server. For example, a customer might down-
load FPOs, place them in a QuarkXPress document, and then want to put the doc-
ument on the service provider’s server. The customer may type in the name of the
file or use the Browse button to point to the file. In many cases, you will want to set
up a separate volume for uploads.
• File Management: This option, when “on,” allows end-users to create folders
inside their WebNative volume, move, rename and delete files.
• Show Archives: This determines whether or not you allow users to search indexes
of archived files.
• Show All Files: Without this checked, a user will only see image files. WebNative
will consider any file for which FullPress makes FPOs to be an image file. Check
FullPress FPO Options settings for your volume if you’re unsure about what
might happen. For more information about possible FullPress settings, refer to
About FPO Options in the FullPress Administration Guide.
Download Permissions
These options allow you to specify the kinds of files each user may download from the
WebNative server. The pop-up list contains combinations of various sorts of files to be
found on the server. Files fall into one of the three following categories:
• High-resolution image files include amy file for which the FullPress server gener-
ates FPOs
• Other high-resolution files not classified as images include files for which the Full-
Press server does not generate FPOs , for example, page layout program files and
spread sheets
• FPOs
The files that WebNative includes in that middle group, other high-resolution files
not classified as images, depends to some degree on to how you have configured
your FullPress server. QuarkXPress and InDesign layout files, for which FPOs are
never generated, will always fit into this class, as will other files such as Excel
spreadsheets and Word documents for which FPOs are not generated. PDF files
and “Vector” EPS files, however, may or may not fall into the group, depending on
whether or not you have decided to produce FPOs for them. If you would like to

42
 Configuring a user’s styles

check your settings for a volume, select that volume from the FullPress
Configuration GUI/File Service/Volume Management GUI and click on the FPO
Options button. Look at settings for:
–Don’t make FPOs for “Vector” EPS files
–Don’t make FPOs for PDF files
The combinations in the Download Permissions pop-up list include:
• Download All Files: This option allows the user to download all files on the spec-
ified WebNative volume.
• Download All Files Except Hi-Res Images: This will allow the user to download
FPOs, layout files and other files for which FPOs aren’t generated. Keep in mind
that Custom Image Order will not work properly without the ability to download
high resolution images.
• Download All Files with No FPOs: This option restricts the user to downloading
files for which FullPress is not making FPO. This is the “middle group” described
above.
• Download All Files Except FPOs: This setting allows the user to download high-
resolution images but not their corresponding FPOs. The user will also be able to
download many other kinds of files, such as QuarkXPress files, InDesign, Excel,
etc., for which the FullPress server does not create FPOs.
• Download FPOs only: With this setting, a user can only download FPOs from the
WebNative server.
• Disable all downloads: This setting means that the user will not be able to down-
load files of any type from the WebNative server.
5. Once you have finished configuring the volume attributes for the user, submit the form
by clicking the Add Volume button. You will have to do this for each user volume you
wish to create.

Configuring a user’s WebNative allows administrators to customize interactions for each user. At the heart of the
styles this system are WebNative styles which can be applied to WebNative actions such as upload-
ing, browsing, image ordering, etc. A style determines the look and feel for an action, or in
other words, what the end-user’s environment looks like, and can be applied for a single
user or many. The style also determines which parts of an action users see.

43
 Chapter 4: General WebNative administration

Clicking on the Styles tab brings up the following WebNative Style Configuration dialog:

Select an end-user
here.

Select a style for

each action from
each pop-up list.

Apply your selec-

tions or to dismiss
the window

FIGURE 17. Establishing which styles users use

Default styles

When you add a new user, he or she will initially be assigned what is known as the default
style for each action. Xinet has preset most of these to the house style. You may change
these default settings if you’d like to have all new users be preconfigured with other set-
tings. For example, in Germany, administrators might want to change the default setting for
language for all new users to Deutsche.

To change default settings, follow the directions in the next section for user styles; but,
select Default in the Username pop-up menu rather than a true user’s name. (It will be the
first name in the list.) Each new user you add afterwards will initially have the style charac-
teristics you set up for the Default user.

Setting up user environments with existing styles

WebNative ships with a few styles already defined for each WebNative end-user action.
Each action has a classic style defined which will set up the user’s environment so that it
behaves just as WebNative 2.0 behaved. Many actions also present alternative house, sim-
ple and list styles which offer more stream-lined interactions. Table 1 contains short
descriptions of existing styles. Table 2 contains a list of actions to which these styles apply.
It also lists which styles pertain to which actions.

TABLE 1. Styles shipped with WebNative

Style name Description

classic Preserves the look and feel of WebNative 2.0
simple A pared-down interface with minimal functions for
image searching, browsing and downloading
house Preserves the functionality of the classic style, but uses
more streamlined icons with roll-over text.

44
Configuring a user’s styles

TABLE 1. Styles shipped with WebNative

Style name Description

classichouse A frameless house style with simplified keyword Search
controls
list A interface optimized for speed of display while main-
taining the most essential features
bigdir A style for browsing large directories, breaking them
into manageable pieces for easier browsing
shortandlist A combination of list and classic
buttons Large buttons for end-user input
smallbuttons Smaller versions of buttons
preview Allows users to zoom/navigate large images
detailed This style give makes available the full set of keyword-
search options that are set up in WebNative Venture
flexible A search style which will be familiar to Macintosh users
changeuser Similar to classic, but provides a button which, at the
Toplevel, allows the users to re-login under a different
Username. Be sure that the user also has privileges to
change his or her password. (You’ll find the User Can
Change Password option under the Users tab.)
housechangeuser Provides a House-style icon at Toplevel that allows users
to re-login under a different Username, regardless of
whether the user has password-changing privileges.
applet Maintained for backwards compatibility. Most sites will
want to use the Xinet Uploader instead. (See page 23.)
appletemail Maintained for backwards compatibility. Most sites will
want to use the Xinet Uploader instead. (See page 23.)
This style combines the applet and email styles. Files
will be sent using an Applet, and email will be sent for
each file uploaded.
email Similar to classic upload, except WebNative will email
the server administrator each time a file is uploaded
formandemail An “educational” upload style so that WebNative devel-
opers can see the full functionality of the upload action.

You will use the Style Configuration interface to choose among existing styles. If you have
created your own styles, they will also appear in the pop-up lists. For more information
about creating your own styles, refer to “WebNative Customization” inside the Xinet Guide
to Development APIs.

45
 Chapter 4: General WebNative administration

To set up an end-user’s environment:

1. Select the user’s name from the Username pop-up list at the top of the page. This list
contains the existing WebNative accounts on the server.
2. Using the pop-up menus below, establish a style for each action that the user will see.
You do no need to change the style from its initial default setting if you want the user to
see the default style.
Table 2 lists the actions that ship with WebNative.:

TABLE 2. Actions shipped with WebNative

Action
name Description Applicable styles
admin Determines the look and feel of the classic
nativeadmin GUI.
basket Determines how the user’s shopping classic
basket window will look and func- house
tion list
browse Determines the appearance for the bigdir
user when he or she is browsing files classic
house
list
shortandlist
simple
css Isolates all Cascading Style Sheets house (CSS properties for the
(CSS) properties in a central loca- house style)
tion.
house_nihongo (Same as
above, only with Japanese
fonts)
classic (empty style for back-
ward compatibility)
icons Determines the appearance of icons buttons
used for such activities as uploading, classic
downloading, etc. house
smallbuttons
imageinfo Determines the appearance and classic
functionality of the Information house
window. list
mviewa Determines how previews of classic
QuarkXPress, InDesign and PDF house
documents will be displayed list

46
Configuring a user’s styles

TABLE 2. Actions shipped with WebNative

Action
name Description Applicable styles
language Determines the language in which classic
the WebNative interface will be seen danish
by the user. Currently, WebNative deutsch
ships with strings defined for Dan- english
ish, English, Finish, French, Ger-
español
man, Japanese, Norwegian, Spanish,
finnish
Swedish, and traditional Chinese. If
you would like to define strings for francais
another language, refer to “WebNa- hangul
tive actions” inside the Xinet Guide islenska
to Development APIs. nihongo
norwegian
swedish
simplified Chinese
traditional Chinese
order Determines the style of the custom classic
order form for the user, if you give house
the user access to one preview
simple
quarkview Legacy name for mview, preserved classic
for backwards compatibility. See house
mview for details. list
search Determines what the user sees when classic
looking at files in search mode classichouse
detailed
flexible
flexhouse
house
list
simple
toplevel Determines what the user sees when bigdir
he or she initially logs in to WebNa- changeuser
tive and what he or she sees after housechangeuser
clicking the Top Level button. classic
house
list
simple
upload Determines the appearance of the applet
user’s interface for uploading files to appletemail
the WebNative server. changuser
classic
formandemail
house
housechangeuser
list
a. Still appears as quarkview in the nativeadmin Styles GUI

47
 Chapter 4: General WebNative administration

3. When you have finished establishing styles for a given user, click on the Submit
Changes button to save them.

You are not necessarily limited to the styles that ship with WebNative. For more informa-
tion about creating your own styles, refer to “Customizing WebNative Styles” inside the
Xinet Guide to Development APIs.

Using volumestyles

There is also a style called volumestyles which can’t be set using the GUI. The WebNative
listdir, imageinfo, and searchengine CGIs have been updated to enable file-system location-
dependent WebNative-style switching. The file which controls this is:
Unix: /var/adm/webnative/volumestyles
Windows: C:\Program Files\Xinet\WebNative\Admin\volumestyles

Files for volumestyles may also be included in the WebNative user or group directory,
where site volumestyles overrides general style assignment, group volumestyles overrides
site volumestyles, and user volumestyles overrides group volumestyles.This is similar to the
WebNative global.js, local.js, and user .js functions order of operations.

Here is a sample volumestyles file entry:

/Volumes/customer/PDFsbrowse:customer_PDF
/Volumes/foocss:foo

Configuring a user’s Plugins control operations users perform on their shopping baskets. You should configure
plugins which ones are available for each user volume. To open the Plugin Configuration window,
click on the Plugins tab, then turn on or off any features you want the user to have access to.
The following window shows the default list:

FIGURE 18. Configuring plugins

48
Configuring a user’s plugins

Default plugins

The default plugins include:

• Administer Baskets: Turning on this option allows users to save and load shopping
baskets. Those functions provide a mechanism for saving the contents of a basket with
a name, and at a later time, returning to the saved basket and performing operations on
it. In the meantime, the shopping basket can be used for new collections of files.
• Download stuffit archive of images: Turning on this option allows users to batch-
download all of the images in their shopping basket as high-resolution images.
• Download stuffit archive of FPOs: Turning on this option allows users to batch-down-
load all of the images in their shopping basket as FPO images.
• Request Shipment: Turning on this option allows users to request that files in the shop-
ping basket be placed on some sort of physical media and sent to them. Users may
request the form of media. The request form will automatically send email to the site
administrator. This plugin has been provided as an example of how to write your own
plugin. See “The WebNative Basket API” inside the Xinet Guide to Development APIs
for details.
• Request Restore: Turning on this option allows users to request that archived images in
the shopping basket be restored. The request form provides a window for them to type
messages about the request. This also is provided, mainly, as an example of how to write
your own plugin.
• Batch Image Order: Turning on this option allows users to quickly convert and down-
load a shopping basket full of images. The mechanism can, for example, convert a bas-
ket of press-ready images into web-ready images or painlessly resize a large group of
images for placement within another document. Parameters include: resolution, dimen-
sions, file format, and color space.
• Batch Keyword Apply [WebNative Venture only]: Batch Apply allows a user to recur-
sively set WebNative Venture keywords for the contents of their shopping baskets. This
is useful when users want to add the same metadata to a group of files.
• Download GIFs [WebNative Portal only]: Turning on this option allows users to make
use of the WebNative Portal One-click Download feature to convert all images in the
basket to GIFs when downloading them.
• Download JPEGs [WebNative Portal only]: Turning on this option allows users to
make use of the WebNative Portal One-click Download feature to convert all images in
the basket to JPEGs when downloading them.
• Download without Clipping Paths [WebNative Portal only]: Turning on this option
allows users to make use of the WebNative Portal One-click Download feature to auto-
matically remove clipping paths from images in the basket when downloading them.
• Asset Fulfillment Request [WebNative Portal only]: Turning on this option allows
users to make use of the WebNative Asset Fulfillment Request (AFR) feature.
• Asset Fulfillment Admin [WebNative Portal only]: Turning on this option allows a user
to become an administrator of the WebNative Portal AFR feature.

Like WebNative styles, you may also write your own WebNative plugins. Refer to “The
WebNative Basket API” inside the Xinet Guide to Development APIs for details.

49
 Chapter 4: General WebNative administration

Shopping basket The WebNative basket

WebNative plugins all operate on the concept of a “basket,” that is, a group of files selected
by a user upon which a particular operation will be performed. A basket contains one or
more files selected from any of the user’s WebNative volumes. In the WebNative interface,
all views of files, with the exception of the icon view, present a “check-basket” for each file.
Checking the basket for a given file adds the file to the current, or default basket. The first
time a user checks a basket for a file in a session, a “basket” window appears as a separate
browser window. (Its exact appearance depends on the selected style.
“Rollovers”, here,
The top row shows icons describe what each icon
for operations that can be will invoke.
performed on the current
basket. Clicking on one of These icons control how
the icons invokes the the basket is viewed (the
operation or a dialog familiar icon, short or
about the operation. long views).
Netscape & Safari users
The main portion of the
will have a Print button
window displays the
which will allow them to
current basket. The user
send the basket, as it’s
can remove items from the
currently being viewed, to
basket by clicking on the
a printer.
item and then “uncheck-
ing” the basket icon or by
Clicking on the waste-
“unchecking” the basket
basket icon removes every-
icon in the main WebNa-
thing from the shopping
tive display.
basket.

FIGURE 19. A user’s shopping basket

Each user has his or her own set of baskets. They are invisible to other users, even if they
share the same WebNative login. The current, or active selection is very important in Web-
Native. All the actions users can request on a group of files are performed on this basket. In
order to perform any action on a group of files, the user must make that group the active
selection.

WebNative allows users to save a basket of files, load a basket of files that have been saved,
and clear the current basket. These operations are invoked by clicking on the shopping bas-
ket icon at the top of the Default basket window. This in turn, opens a series of windows.
WebNative does not let users perform plugin operations on anything but the active basket. All
operations are implemented using the Basket API.

The next section describes how the Basket APIs operate. You should be able to extrapolate
from the general description and write your own.

Default administration actions for shopping baskets

Any user allowed to administer a shopping basket will have the features described in this
section. (Users gain access to this interface by clicking the shopping basket in the top left

50
Shopping basket

corner of an open basket.) You, of course, may add to the operations your users can perform
on baskets. The following illustration presents an overview of the default features:
The top section allows
users to assign names to
baskets so they can be
saved for later use. Users
can also empty the
contents the “current”
basket.

The lower section

provides a mechanism for
selecting previously saved
baskets and performing
various operations upon
them.

FIGURE 20. Default shopping basket features

Saving baskets

Sometimes a user will generate a basket, and want to save this grouping of files for later
use, e.g., the user is waiting to add additional files to the basket. The basketadmin plugin is
a standard plugin that performs this operation. When users request to save a basket, they
will be prompted to name the basket if they have not already typed in a name in the New
Basket Name box. Note that saving a basket saves only that logical grouping of the files. It
does not save the files themselves. Being saved as a member of a basket does not prevent a
file from being deleted or modified.

Selecting an existing collection

Because operations can only be performed on the active selection, there is an option to
allow loading of saved baskets into the active window. Users may select existing baskets
from the pop-up menu, and add the contents to the current basket, replace the current basket
with the contents, or delete the selected basket. The act of loading a basket does not alter the
fact that the basket is saved.

Clearing baskets

WebNative will remember the user’s baskets, including the active basket, even between ses-
sions. The user could empty the entire basket by unchecking each box, but that is cumber-
some. The Clear basket function allows an entire basket to be cleared in a single operation.
Just as saving a basket does not save the actual files, deleting a basket does nothing to the
actual files, it just removes their logical
association.

Shopping basket plugins

There are a number of commercially-available plugins that have been developed for Web-
Native to facilitate specific jobs. Your Authorized Xinet Integrator can provide you with
more information about any of these plugins.

51
 Chapter 4: General WebNative administration

Modifying access to user You may modify a user’s previously-established access to a volume, or in other words,
volumes change a user’s volume interaction permissions. To do so:

1. Click on the Volumes tab.

2. Select the user name in the Volumes for pop-up menu. A list of all volumes to which
you’ve previously given that user access will appear, as shown below:

FIGURE 21. A user’s volume access

3. Click the Modify button next to the volume for which you want to modify the user’s
access. The Modify Entry dialog will appear, as shown below:

FIGURE 22. The Modify Entry dialog box

4. After you have made changes, click on the Submit Changes button to save them.

Removing access Denying access to a volume to which a user previously had permission to see is straightfor-
privileges to a user ward. Don't worry if you delete access to a volume by accident. You're not deleting any files
volume from the server; you're only removing a user’s access to files in that volume via the Web.
You can easily re-establish access by republishing the volume. To remove access privileges
to a volume:

52
 Creating and editing groups

1. Select the Volumes tab.

2. Select the user name in the Owner pop-up menu. A list of all volumes to which you’ve
previously given that user access will appear.
3. Click the Delete button next to the volume in question.

Creating and editing The Groups tab has three subpanels which allow you to edit existing groups, add new
groups groups, and delete groups. You can switch between these by clicking the subpanel links on
the dark blue bar in the GUI. Adding new groups and editing membership for existing
groups are similar activities. For either, follow these steps:

1. Select the Groups tab.

2. Establish the group. If it is a new group, click the New Group link and type in the name
in the Group field. If it is an existing group whose membership you are modifying,
choose the group with the pull-down Group menu. If an asterisk appears next to a
group name, it means the group has a subadministrator.
3. Existing WebNative users appear in the Members list. Click on user names to add or
remove them from the group membership list. A check mark appears next to any name
that is a member of the group.
4. When you are satisfied with your settings, click on the Add Group or Submit Changes
button. You may also click on the Dismiss button if you do not want to save what
you’ve just done.

Deleting users or groups To delete any WebNative user or WebNative group:

1. Click on the User or Group tab in the WebNative Administration window, then either
the Delete User or Delete Group link.
2. Select the appropriate name in the Username or Group pop-up menu.
3. [optional] When deleting a user, decide whether you want to preserve the user’s folder
within the WebNative administrative area on your server. If you do not check the box,
the directory /var/adm/webnative/user_name (UNIX systems) or C:\Program
Files\Xinet\WebNative\Admin\user_name (Windows systems) and its contents will be
deleted from the server when you delete the user. Some administrators may want to
preserve the files so that they can use the soon-to-be-deleted user settings as a template
for future users.
4. Click on the Delete User or Delete Group button.
5. WebNative will ask you to confirm that you truly want to delete the user or group.

Enabling WebNative’s subadministration option allows you to give some users special permission to
Subadministrators take over basic administration tasks without turning over full
nativeadmin powers. For example, if you had a customer with a large number of users, you
might want someone at the customer’s site to take on setting up accounts and passwords for
users. This might be more convenient for the customer and benefit you by reducing your
administrative overhead. The SubAdmin subpanel under the Users tab allows you to set up
subadministration.

53
 Chapter 4: General WebNative administration

When you give subadministration powers to a user, you give that user limited administra-
tive powers over only a single group, and only over the volumes to which he or she already
has access. Once empowered, the subadministrator can take on day-to-day administrative
tasks for that group, but for that group alone. Other groups on the server remain hidden
from the subadministrator.

While authenticated as a subadministrator, the user sees a subset of the tabs you see as
nativeadmin. Subadministrators do not have access to anything under the Styles tab nor
most WebNative Venture tabs. They do see, and can make changes to, attributes found
under the following tabs:
• Volumes
• Users
• Groups
• Plugins
• User Perms
• Logs

This access allows subadministrators to take on such tasks as:

• Creating subgroups for their organization
• Adding existing users to the groups and subgroups
• Creating new users and helping those who have forgotten passwords

As nativeadmin, you can always see and change anything a subadministrator does. Unless
you setup multiple subadministrators to a single group, one subadministrator will not have
knowledge of any other subadministrator’s area.

Subadministration licensing

Each WebNative installation ships with a complimentary subadministrator’s license. If you

would like to add additional subadministrators, please contact your Authorized Xinet Inte-
grator.

Setting up a subadministrator

Please note that subadministration depends on having first set up groups. If you need help
setting up groups, please refer to “Creating and editing groups” on page 53.

To set up a subadministrator:

1. Under the User’s tab, click on the SubAdmin link to open the subpanel.
2. Choose a user name from the User Name pop-up window. (Remember, the users needs
to be a member of the group for which you’re enabling subadministration privileges.)
An asterisk next to a user’s name means that he or she is already a subadministrator.
3. Check the Enable SubAdmin box.
4. Choose a group for the person to manage. A user can only subadminister one group at a
time.

54
 Changing the nativeadmin password

5. While many subadministrators will create the subgroups their site needs, you may also
give them access to existing subgroups. Your strategy will probably depend on if you
have previously managed groups and users for the site or if you’re setting things up for
the first time. Pay attention when assigning subgroups, for you don’t want to
mistakenly grant privileges to members of a subgroup who aren’t members of the
group itself. WebNative will, in fact, not let this happen, but will force you to make
decisions about membership if you try to violate the condition.
6. Click the Submit button when you are satisfied with your setting.

Notes for subadministrators

You may want to pass on information to subadministrators about authenticating themselves

as a subadministrator. Here are the steps:

1. Login to WebNative as usual.

2. [This step may vary slightly, depending on Styles settings.] If assigned toplevel House
style, click on the Preferences icon and then Change Password; if assigned toplevel
Classic style, click the Change Password button directly.
3. Once inside the Change Password GUI, click on the SubAdmin button. (One doesn’t
need to actually change the password.)
You’ll see the WebNative Subadministration GUI.
4. If you have question about the interface, try the Help buttons.

Changing the To change the nativeadmin password:

nativeadmin password
1. Select the Users tab in the WebNative Administration window, and then, the Users link.
2. In the pop-up menu, select the user nativeadmin.
3. Type a new password and verify it.
4. Click on the Submit Changes button.

Take care to remember the new password.

Viewing WebNative WebNative provides access logs so that you can monitor how WebNative is being used. The
access logs Logs GUI presents an easy way to look at what’s happening. You can also parse the access-
log file on the server with other programs or scripts to automatically generate invoices, if
you charge on a per-usage basis. Xinet TechNote 102 available at www.xinet.com provides
more information about this.

55
 Chapter 4: General WebNative administration

Navigating the log on-line is quite straight-forward:

1. Click on the Logs tab. The following GUI will appear:

FIGURE 23. Viewing the log files

There are three subpanels:

• The Access Log, which is discussed in this section, provides information about
database users and their activities.
• The Venture Log provides information about database errors.
• The Trigger Log provides a record of events happening through Triggers.
“Advanced troubleshooting of WebNative Venture Triggers and Actions” on
page 174 provides information about understanding a Trigger Log.
2. Select the user whose usage you want to look up in the Access Log for user pop-up list.
Note, that you can also choose to view system-wide WebNative activities by selecting
All Users.
3. Establish the period of time over which you would like to gather usage information by
setting the Start date and End date.
4. Establish the level of detail in the report you’ll see by selecting one of the Log type
options. You may choose between:
• Full Listing
• Summary Only
• Uploads Only

56
Viewing WebNative access logs

5. Click the View Log button to update the screen. What you see next depends on the log
type you’ve requested. Figure 24 shows a full listing:

FIGURE 24. An example of a full-listing log file

Interpreting what you see

If you decide to show full listings in the log, the top portion of your report will show a chro-
nological listing of WebNative activity on a file-by-file basis, including information about
who did the download/upload, the machine address where the activity originated, the name
of the file, the file’s type, the size of the file on the server, and the size of the compressed file
actually sent. WebNative provides the compressed file information because some Internet
users are actually charged for the amount of bandwidth they use and may want to pass that
expense on to the user.

If you want more information about a particular file, you may click on the file name in the
table and open the file’s information page. Clicking the “Cancel” button there will return
you to the log file.

Finally, by scrolling to the bottom of the page, you’ll find a Usage summary where total
amounts from the detailed list above are given.

Some administrators may want to make further use of information collected in the log.
Information on all downloads/uploads via WebNative are kept in the file
/var/adm/webnative/accesslog on UNIX systems and C:\Program Files\Xinet\WebNa-
tive\Admin\accesslog on Windows systems.

The format of the accesslog file is designed to facilitate easy parsing by C programs, Perl
programs, and UNIX shell scripts. In addition, you can import the data into Excel.The gen-
eral idea is that you should be able to easily determine which user has downloaded or
uploaded images and be able to charge them based on a variety of criteria: the size of the

57
 Chapter 4: General WebNative administration

files, whether they accessed high-resolution or low-resolution files, the number of actions,
etc.

New entries are always added to the bottom of the accesslog file. The format of each entry
is standardized, but the format itself has been improved with successive releases.

Log entries prior to April 2006 will look like this:

1 Mar 2 10:37 fred 131.106.110.77 /playland/lab.nobackgroundnewname 2

1 Mar 2 10:37 fred 131.106.110.77 /playland/lab.nobackgroundnewname 4

2 Sep 25 16:38 fred 131.106.110.87 /playland/barco/gotolinetest 4 54178 9212

2 Sep 25 16:38 fred 131.106.110.87 /playland/barco/gotolinetest 256 67512 16776

3 926545625 foo 131.106.110.77 /images/testimages/77083_1 256 18598890 9788792

The current format of log entries is like this:

4 1150985553 grover 131.106.110.74 /space/TPT14606222.indd n/a 2 135597 135597

Here is what each field records:

• field 1: a numeric value of 1, 2,3 or 4.
If this field is a 1, then the format of the entry is the first format used in WebNative (i.e.
the oldest format we have used.) If it is 2, the format is the second type used for the file,
etc. The current format is represented by a 4 in this field.
Any script/program that parses the fields of this file should look at this first field to tell
what format to expect in the entry.
• field 2: the second field indicates the time of the download.
In the current format, the time is given in UNIX time, meaning seconds since January
1st, 1970. The advantage of this format is that it can be converted to local time using
whatever format is appropriate. For instance, the date can be converted to European
standards (with the day first and month second) or to non-English spellings of months.
It is also simpler to store the date in one field rather than three.
If you were parsing the file using a C program, you might use ctime to convert the
seconds into the local time. Or, if you were using an SGI system, you might use
amtime1970 -d in a shell script, as shown below:
root@server: -> amtime1970 -d 941217114
Fri Oct 29 10:11:54 1999
See the UNIX man pages for more details about amtime1970 and ctime.
One might also do the conversion using Perl. A simple macro, such as the example
below, would convert the date for Excel:
Sub ImportAccessLog()
'
' ImportAccessLog Macro
' This Macro imports a file in the WebNative AccessLog format, where
' the second field indicates the time of the download in Unix time, i.e.
' "seconds since January 1, 1970." The file is imported, and then the

58
Viewing WebNative access logs

' time is converted to Mac Excel time, which is "seconds since January 1,
' 1904." For use with Windows Excel or with a Mac where the time system
' of "seconds since January 1, 1900" is in use, change 24107 in the macro
' to 25569.

'Pop up dialogue to select file

myfile = Application.GetOpenFilename("TEXT")
Workbooks.OpenText _
FileName:=myfile, _
Origin:=xlMacintosh, _
StartRow:=1, _
DataType:=xlDelimited, _
TextQualifier:= _
xlDoubleQuote, _
Tab:=True, _
FieldInfo:=Array(1, 1)
' Insert a new column for the new dates
Columns("C:C").Insert Shift:=xlToRight
' Find the last cell in use
Selection.SpecialCells(xlCellTypeLastCell).Select
' Range is set to first through last cells to use in the new column
Range("C1", ActiveCell.Offset(0, -6)).Select
' Set the formula. This value is for the 1904 date system. If the 1900
' date system is in use, change 24107 to 25569.
Selection.Formula = "=PRODUCT(RC[-1],1/86400) + 24107"
' Convert formula to values so the original values can be deleted
Selection.Copy
Selection.PasteSpecial Paste:=xlValues, Operation:=xlNone, _
SkipBlanks:=False, Transpose:=False
Application.CutCopyMode = False
' Delete the original date column
Columns("B:B").Delete Shift:=xlToLeft
' Set the format for the new date column
Columns("B:B").NumberFormat = "m/d/yy h:mm"
End Sub

The earlier formats (1 and 2), are slightly different: In the first format, there are no file
sizes given (fields 7 and 8) and the date is a character string rather than UNIX time. The
second format has file sizes but the date is still not UNIX time. Note that there is no year
listed in the first or the second format.
• field 3: the Webnative user who did the download/upload.
• field 4: the IP address of the machine that the images were downloaded/uploaded to/
from.
• field 5: the full path of the image that was downloaded.
• field 6: the place to which a file has been moved via the WebNative File Manager facil-
ity. In most cases, because File Manager hasn’t been used, the field will be marked n/a.
• field 7: the exact action by the user. Each number represents the following action:

TABLE 3. WebNative File Manager activities

number action
1 a new directory created
2 a user downloaded a large web preview
3 a user downloaded an FPO

59
 Chapter 4: General WebNative administration

TABLE 3. WebNative File Manager activities

number action
4 a user copied a file
5 a user moved a file
6 a user deleted a file
7 a user downloaded a high resolution image
8 a user uploaded a file
9 a user used the WebNative Custom Image Order feature

Viewing the 72 DPI preview is listed as an action you may want to charge for because
these previews are web-ready. In other words, they can be copied by a WebNative user
and incorporated as an image onto another website.
• field 8: the size of the image on the server; i.e. the image in its decompressed state.
This field allows you to charge by the bytes taken up on the server.
• field 9: the size of the image as it is sent over the Internet; i.e. the image after it is com-
pressed.
This field allows you to charge by the bytes taken up on the Internet (bandwidth) by the
download/upload.
Note that the compressed size is not always smaller than the uncompressed size. If the
file is an FPO, then the compressed version will not be smaller. Sometimes the headers
added in the compression process make the compressed file larger than the original.

Additional logs about previews stored in the WebNative Venture database

Creating web previews for multipage InDesign, QuarkXPress, and PDF files and writing
them directly into the WebNative Venture database is a CPU-intensive process. Your server
logs information about the process, but you’ll find that information inside the FullPress
GUI rather than in the nativeadmin GUI discussed on the proceeding pages. That’s because
behind the scenes, the FullPress mkfpo(1) program does the work, communicating with the
WebNative Venture dblogd(1M) program about the process.

The mkfpo(1) program reports errors about difficulties in making previews. You can find
these summarized in the log file presented by the FullPress GUI/File Service, Status &
Config/ FPO Logging/View log file button. You might want to look here, for example, if you
hear complaints about system performance or perhaps when a web preview doesn’t show
up as expected. (Perhaps someone has just copied 500 multipage PDF documents onto the
system or imported 7,000 digital camera files.) Your Xinet integrator or Xinet Technical

60
Viewing WebNative access logs

Support might also ask you to email the contents of this log file. Figure 25 provides an
example of a FullPress log containing database information.

FIGURE 25. FullPress FPO Generation Log showing WebNative Venture activity

61
 Chapter 4: General WebNative administration

62
 Strategy 1: Customers have access to active and archived jobs

Chapter 5

File system organization for Webnative

WebNative works hand-in-hand with the file structure of your system. The way you orga-
nize customer and/or job files on your server affects which files customers can see and use,
and how the files are organized through WebNative for their use. We encourage you to think
about how your file structure integrates with your preferred workflow, with WebNative, and
your archiving scheme, and to choose a structure that makes sense for all.

The following subsections describe several WebNative-assisted workflows and file system
strategies which suit them. One of them should work as a model for most situations.

Strategy 1: Customers If you would like to give customers access to all their files, both active and archived, you
have access to active and might want to consider organizing your files as shown below.
archived jobs
This structure provides the advantage of allowing you to archive and restore files exactly as
they appear in your working directories.

Ticket
1237
Customer 1

Ticket
Customer 1
2555
WebNative points
here

Ticket
3216

Ticket
raid 6266
Campaign 1

FullPress volumes
Customer 2 Ticket
start here
6777
Customer 2
WebNative points
here
Ticket
33255
Campaign 2

Ticket
34111

Ticket
1237
Customer 3 Ticket
34258

Customer 3 doesn't Ticket

have WebNative access 2555

Ticket
3216

FIGURE 26. Access to active and archived jobs

63
 Chapter 5: File system organization for Webnative

Strategy 2: Customers Some production facilities may not want customers to have access to elements of jobs in
only have access to progress. It is easy to arrange your files to work easily with WebNative in this fashion. This
archived jobs workflow needs a bit more attention than the previous one: you must move a job to the
appropriate area of the file system when you have finished production. It’s a good workflow
when you intent to use Triggers and Trigger Sets. Refer to “Actions and Trigger Sets quick-
start guide” on page 137 for details about these.

Ticket
1237
Move finished jobs to
Work Area the appropriate customer
area of the archive.
Ticket
Customers don't
2555
have access to
files in this area

Ticket
3216

raid

FullPress volumes
start here

Ticket
6266
Customer 1

Archives
Customer 1 Ticket
WebNative points 6777
here

Ticket
33255
Customer 2

Ticket
Customer 2 doesn't
34111
have WebNative
access

Ticket
34258

Ticket
1245
Customer 3

Customer 3 Ticket
WebNative points 8883
here

FIGURE 27. Access to archived jobs only

Strategy 3: You keep Some production facilities may want tight control over files to which WebNative customers
tight control over files can gain access, even if it means extra administrative work. Working files would be strictly
customers can see off limits to customers, as well as archives of finished jobs. In this scheme, you set up a

64
Strategy 3: You keep tight control over files customers can see

“loss area” strictly devoted to WebNative downloading and uploading. The following struc-
ture shows one possibility:

FIGURE 28. Keeping control over files customers can see

This “loss area” could even be on a separate machine or the other side of a firewall.

65
 Chapter 5: File system organization for Webnative

Here is another possible organization for Strategy 3:

FIGURE 29. Another strategy for keeping control over what customers see

Strategy 4: You do You can set up a file structure where you only use ticket numbers for WebNative organiza-
everything by ticket tion, if that is the way you already track your jobs and don’t want to change. To do so, you
number would make a new WebNative volume every time you open a new ticket. You could auto-
mate that with a WebNative trigger (See “Actions and Trigger Sets quick-start guide” on
page 137 to get started), or do it by hand.

66
Strategy 4: You do everything by ticket number

When you archive, you’d archive whole tickets to which you could also give customers
access. The following file structure would be appropriate to this workflow:

Because you track

Ticket everything by ticket
1237 number, you make
individual tickets or
ticket archives into
WebNative volumes.
Ticket
2555

Ticket
3216

raid

You do not necessarily

FullPress volumes Ticket
have to do so for
start here 6266
every ticket.

Ticket
6777

Ticket
33255

Ticket
34111

FIGURE 30. An organization by job ticket number

67
 Chapter 5: File system organization for Webnative

68
 Overview

Chapter 6

WebNative Security

Overview The Web presents a unique set of trust and security issues that businesses must address to
minimize risk. The purpose of this chapter is to educate end users and integrators about the
real risks related to doing business on the Internet. Included are suggestions for securing
your WebNative server to decrease the likelihood of a successful “hacker” attack.

There is a lot of misinformation and hype about hacking (or cracking to be more precise).
Sensationalism from the news media and Hollywood turned the issue into one of magical
and mystical proportions that does not accurately reflect what is really going on in the real
world.

Hackers are usually after one of several things:

• Access to a system that will allow them to cover their tracks when hacking other sys-
tems. This is usually about finding open email systems to forward emails anonymously,
or opening proxy servers to anonymously forward their HTTP requests, or locating an
open FTP server to deposit pornography or pirated software to share with others.
• Access to a system to provide a platform to launch a denial of service attack against
someone else.
• For the thrill of beating someone’s security and just having a look around… and possi-
bly finding credit card information.
• Industrial espionage. This one is very hard to harden your site against since these attack-
ers have big budgets and state of the art equipment and tools. Most industries and compa-
nies will have very little to worry about from this kind of attack.

Remember that most hackers probing your defenses will be “script kiddies” or other ama-
teurs that are just looking around. These people can be stopped fairly easily since they will
not spend any time poking at your system if their initial probes show you have spent the
time to plug the obvious and common security holes.

You do not need to be afraid to connect your servers to the Internet. Just do your homework,
read all the documentation, and follow the guidelines below and statistically you will
reduce your risk to nearly zero. Remember that no security system is impenetrable, so you
still need to make plans for the worst-case scenario.

Some groundwork Anatomy of a web transaction

Definitions

URL stands for Universal Service Locator. A URL Consists of 2 items: protocol and
location

DNS stands for Domain Name Service

69
 Chapter 6: WebNative Security

Protocols can be one of the following: http://, ftp://, nfs://, afp://, https://, etc. The protocol
can also contain a port number, but the well known port number of the requested service is
assumed if no port is specified. An example of a port number is http://www.foo.com:8080.
In this case 8080 is a custom port number to which an http service is attached. More about
this later.

For example, the location: www.foo.com/test/mypage.html consists of the DNS name of the
server and a relative path to the requested file.

What happens when a user enters a URL in a browser?

1. Client does DNS lookup of location part of URL to determine IP address.

2. Client connects via TCP/IP to the server and sends HTTP request.
3. Server analyzes the request, checks credentials, then reads files from local storage and
sends first MIME header and then data.
4. Server makes a log entry of the transaction and may do a DNS lookup if the client
receives the data. It also formats it for the user or calls a helper application based on the
MIME header.

What does destination port number XXX mean?

A connection consists of the pair of IP addresses that are talking to each other, as well a pair
of port numbers. The destination port number often indicates the type of service being con-
nected to. This section describes some of the meanings of these port numbers.

Port numbers are divided into three ranges:

• The Well Known Ports are those from 0 through 1023. These are tightly bound to ser-
vices, and usually traffic on this port clearly indicates the protocol for that service. For
example, port 80 should always be used for HTTP traffic. On UNIX systems these Well
Known Ports can only be accessed by processes that are owned by root. This prevents
user-level processes from impersonating these services and hijacking them.
• The Registered Ports are those from 1024 through 49151. These are loosely bound to
services, which means that while there are numerous services “bound” to these ports,
these ports are likewise used for many other purposes. For example, most systems start
handing out dynamic ports starting around 1024.
• The Dynamic and/or Private Ports are those from 49152 through 65535. In theory, no
service should be assigned to these ports.

If you would like a comprehensive list of these, on any UNIX machine (OSX, Sun, SGI,
Linux) you can open a terminal and type > more /etc/services.

In order for someone to gain access to your system, there must be something listening to a
port that can pass command and control information or can be used to transfer the contents
of a file to or from the server. Examples include telnetd and ftpd, both daemons that listen to
ports. It is very important that all unnecessary daemons are turned off. It is also important
that any necessary demons like Apache’s httpd be configured correctly.

None of the WebNative CGIs can pass command or control information to/from the native
OS via httpd. As an added security feature, the CGIs are also specifically designed to be

70
 Securing your WebNative server

incapable of accessing sensitive configuration or password data. Remember, systems are

“hacked” by exploiting a weakness in a CGI or in the web server itself to get information
about the system’s configuration that would allow an attack through a bi-directional link,
such as a terminal session. If all those bidirectional links are closed, they can’t be exploited
even if someone were to somehow get a password for the system (perhaps from those pesky
users who put their passwords on stickies on their monitor or use easy to guess passwords).

Authentication

The biggest security weakness in any system is usually its users. Therefore an important
line of defense is choosing and enforcing a good password policy.

Let’s take a look at Basic Authentication, the most common authentication mechanism in
use today. When a user’s browser asks a server for a page, the server matches the URL
against a list. If there is a match, the server sends the browser a “realm” to which the client
must authenticate. The browser displays this realm string and prompts the user for a user-
name and password that is valid in the given realm. The browser then passes this username
and password back to the server in clear text when it retries the original request. (The user-
name and password are obfuscated with Base-64.)

There are several other authentication schemas that you can use including Kerberos and
LDAP. As WebNative uses the built-in Apache authentication, whatever method you imple-
ment should work but you must test it first as Xinet can’t qualify every possible combina-
tion. Using a third-party authentication module rather than just Basic Authentication will
allow you to increase authentication security. The reason for this is that they often support
stronger encryption algorithms including the ability to use biometric and smart card input
from client-attached modules. Using an authentication module such as mod_ldap will
allow you to centralize the authentication for all of your network services.You may also
wish to consider using SSL for the target realm to ensure that the authentication is encrypted
when it is passed to the server.

The URL to an https connection looks like this:

https://www.foo.com/webnative/listdir

Securing your The basics

WebNative server • Make sure you have the latest version of Apache.
• Make sure all of the current OS patches and updates have been installed.
• Make sure the OS itself has been secured properly. This is the most common way hack-
ers get in, not via the web server itself.
• All administrators should have their own accounts and use sudo rather than login in as
root. This provides a double layer of authentication.
• Make regular backups and test them for restoration integrity.
• Do not accept ICMP redirects or pings on broadcast addresses. This insures that your
server or network remains invisible to people using programs to search for live
machines to probe further.
• IP source routed packets should be declined.
• Do not allow packets into your network from outside that have an inside source address.
• Do not allow packets out of your network that have an outside source address.

71
 Chapter 6: WebNative Security

• Shut down all unnecessary ports on the web server. You should only have www, http,
https, email, dns, ssh, and sftp enabled (as needed).
• Use secure protocols such as ssh and sftp rather than telnet and ftp.
• Install a firewall and use either a proxy server or NAT/Virtual servers to provide a secure
buffered communication channel between the WebNative server and the outside world.
See “Other security measures” on page 73 for more details.

What do all these things in httpd.conf mean and what should I set them to?

Here is a list of some of the tags you should look at in the httpd.conf file. You really must
also read the documentation from apache.org for more information. As a rule of thumb, you
should turn off everything you don’t absolutely need.
• ServerAdmin– This should be a real email address.
• User & Group– This should never be root, create ones for the server
• Indexing– [NO] This means that clients can’t get directory listing — knowledge is
power for a hacker.
• ServerType– Standalone
• MinSpareServers– [5]
• MaxSpareServers– [10]
• StartServers– [5]
• MaxClients– [150] Set a reasonable number of threads to keep the system from being
overwhelmed by a denial of service attack (DOS)
• MaxRequestPerChild– [30]
• Timeout– [300] Set time in seconds to wait for get, put, ack, post.
• ServerSignature– [OFF] Again, knowledge is power to a hacker so don’t tell clients
what kind or version of web server software is running.
• LogTypes– {Referrer, Agent, Access/Transfer, Error, Combined, Scriptlog}—Choose
what types you really need and turn off all others. For improved performance, consider-
putting logs on a separate file system.
• LogLevels– {Emerg, Alert, Crit, Error, Warn, Notice, Info, Debug} — Choose Warn or
Notice unless you really need more information.
• KeepAlive– [ON] This provides persistent connections and speeds up image fetches.
• MaxKeepAliveRequests– [100] Put a reasonable limit on this so a single connection
can’t hog the server.
• KeepAliveTimeout– [15] Time to actually keep the connection open
• ListenBacklog– Maximum length of request queues
• HostnameLookups– It is best to leave this off unless you really need hostnames in your
log files. You can post process the logs and do the lookups at that time if you want.
• FollowSymLinks– [OFF] Causes multiple lsstat commands for short and long URLs.
Only turn this on if you really need it
• SymLinksIfOwnerMatch– [OFF] As above
• AllowOverride– [NONE] — This will keep Apache from trying to open a .htaccess file
in every directory it touches.

72
 Other security measures

Robots, spiders and web crawlers

These are programs that automatically traverse the Web’s hypertext structure by retrieving a
document and then recursively retrieving all documents that it references. That is how
indexing sites and search engines, such as Google, are able to tell you where everything is
on the Internet. Unfortunately, it also is the method some hackers use to find sites to investi-
gate more thoroughly.

Protecting your site:

1. You should create a file in your web server root directory called robots.txt and put the
following two lines in it:
User-agent: *
Disallow: /
2. You will also want to add the following to the header of your root page:
<HTML>
<Head> <Title>title of your page</Title>
<META name="robots" content="noindex,nofollow">
<META name="description" content="description of your
page">
</Head>
<Body> ...

This will keep most properly-behaved robots from indexing your website. Remember, the
less information your server broadcasts or allows out voluntarily, the less chance it will be
noticed by a hacker.

Other security measures Proxy and reverse-proxy servers

Proxy servers and reverse-proxy servers are applications that get in between the user’s
browser and the web server. These are usually used inside a firewall to allow users to con-
nect to the outside world. When using a proxy server, an outgoing request from a client
browser is intercepted by the proxy server and matched against a set of rules. If the request
meets the rules of acceptability, it is forwarded to the destination with the source address set
to the proxy server, not the original client. The destination web server then responds to the
request from the proxy server, which processes it through a set of acceptability rules then
passes the response onto the original client.

A reverse-proxy does the same thing but is set up outside the firewall and accepts requests
from the outside world and passes them securely through the firewall to the destination web
server.

One of the most popular ways of implementing a proxy or reverse-proxy server is to use the
Apache mod-proxy module. By setting up a very stripped-down server (running Linux
would be ideal) and using Apache with mod-proxy, you can build a very inexpensive and
secure proxy server.

Here is an example of what to put in the Apache httpd.conf file of your reverse proxy server:
ProxyRequests off
ProxyPass / http://192.168.111.212/

73
 Chapter 6: WebNative Security

ProxyPassReverse / http://192.168.111.212/

This setup disables the forward proxy so it can’t be hijacked. Then, it remaps all incoming
WWW requests to the inside server (192.168.111.212). (The inside server could have been
set to a non-standard port to make it even more secure.)

Firewalls

Firewalls are applications or hardware devices that are placed between your internal net-
work and the Internet. The firewall will look at all packets that go in or out and compares
them to a set of rules that allow you to precisely define what can and can’t go in or out of
your network. Firewalls are usually placed on the LAN side of your Internet router or are
sometimes built directly into your Internet router. The term “DMZ” refers to the network
between the Internet router and the firewall. This network zone is usually where external
web servers or proxy servers are placed along with mail servers, DNS servers, etc.

Here is an example of some ACL statements for a CISCO firewall that permits only the com-
munication from the proxy server (192.168.1.211) to the inside web server
(192.168.111.212) and denies all other traffic:
access-list 101 deny ip 0.0.0.0 255.255.255.255 0.0.0.0
255.255.255.255
permit tcp host 192.168.1.211 host 192.168.111.212 eq www
deny ip all host 192.168.111.212

NAT — Network Address Translation and virtual services

NAT is a service that is commonly built into firewalls that remaps all traffic coming from the
inside network to a single outbound source address. Systems that provide NAT also often
provide virtual servers or services. This technology remaps all packets destined for a certain
port and addressed to the firewall to specified servers inside the firewall. Basically, this is a
lot like a reverse proxy server only configureable for multiple applications.

There are many inexpensive firewall/NAT/virtual server boxes available on the market. Any
one of these will provide a significant amount of security to your WebNative server.1

VPN — Virtual Private Network

If you want the ultimate in security for a select group of customers, you can implement a
VPN. On your end, you need either a hardware or software based VPN concentrator. The
clients (your customers) would have to have VPN client software loaded on their computer
and you would have to give them a VPN login ID and password. Once they have authenti-
cated to the VPN concentrator, their client computer would be essentially inside your net-
work on a virtual circuit. All traffic would then be encrypted as it passes along the virtual
tunnel across the Internet. You would connect your web server to the other side of the con-
centrator using a separate network card in the server so that the concentrator would not be
connected directly to your main network.2

1. An excellent example of one of these devices is the Linksys Instant Broadband™ EtherFast®Cable/DSL Firewall Router (BEFSX41) [see http://
www.linksys.com/products for more info]. It is very inexpensive, provides all of the above services, and is designed for even the novice administra-
tor to secure his or her network with only a few minutes of work. If you have a much larger budget, then have a look at the products offered by
Cisco, as they are considered the market leader in Internet security hardware.

74
Other security measures

SSL— Secure Sockets Layer and TLS (Transport Layer Security)

The Secure Sockets Layer protocol is a protocol layer which may be placed between a reli-
able, connection-oriented network layer protocol (e.g. TCP/IP) and the application protocol
layer (e.g. HTTP). SSL provides for secure communication between client and server by
allowing mutual authentication, the use of digital signatures for integrity, and encryption for
privacy.

The protocol is designed to support a range of choices for specific algorithms used for cryp-
tography, digests, and signatures. This allows algorithm selection for specific servers to be
made based on legal, export or other concerns, and also enables the protocol to take advan-
tage of new algorithms. Choices are negotiated between client and server at the start of
establishing a protocol session. A secure session goes something like this:

1. Client initiates connection.

2. Server responds, sending the client its digital ID. The server might also request the
client’s digital ID.
3. The client verifies the server’s digital ID. If requested, the client then sends the server
its digital ID.
4. When authentication is complete, the client sends the server a session key encrypted
using the server’s public key.
5. Once a session key is established, it is used to commence secure communications
between the client and server.

You can run mod_ssl or Apache_SSL to provide your end users with a secure 128-bit
encrypted link to your site. Both of these use OpenSSL to provide SSL v2/v3 and TLS v1.

The heart of this system is a asymmetrical public/private encryption key schema and a cer-
tificate. A certificate associates a public key with the real identity of an individual, server,
or other entity. Certificates are related to public key cryptography by containing a public
key. To be useful, there must be a corresponding private key somewhere. With OpenSSL,
public keys are easily derived from private keys, so before you create a certificate or a certifi-
cate request, you need to create a private key.

Private keys are generated with openssl genrsa if you want a RSA private key, or openssl
gendsa if you want a DSA private key.

To create a certificate, you need to start with a certificate request (or, as some certificate
authorities like to put it, “certificate signing request”, since that’s exactly what certificate
authorities do: they sign it and give you the result back, making it authentic according to
their policies). A certificate request can then be sent to a certificate authority to get it signed
into a certificate. Or, if you have your own certificate authority, you may sign it yourself,
which is useful if you need a self-signed certificate because you just want a test certificate or
because you are setting up your own CA.

The certificate request is created like this:

2. Look to companies like Cisco and Linksys to check out VPN concentrators. MacOSX 10.3 has support for VPN built in, but requires a concentrator
that supports “L2TP over IPSec” or “PPTP”.

75
 Chapter 6: WebNative Security

openssl req -new -key privkey.pem -out cert.csr

Now, the file cert.csr can be sent to the certificate authority, if they can handle files in PEM
format. If not, use the extra argument -outform followed by the keyword for the format to
use.

When the certificate authority has then done the checks they require (and probably gotten
payment from you), they will hand over your new certificate to you.

Running SSL means that clients will have to connect to your server using the
https:// protocol over port 443 rather than the normal port 80. Connecting to port 443 hap-
pens automatically when using https:// in a standard web browser.

To set this up, you will need to download OpenSSL then either mod_ssl or
Apache-SSL. You will then need to acquire a security certificate from one of the signing
agencies, such as Verisign. In order to get one of these certificates, you will have to prove to
the signing authority exactly who you are. By doing this, everybody can be assured that
connecting to an SSL enabled site is truly secure.

Here is an example of entries that you would need to put in your httpd.conf file to make http
and https work using Apache-SSL:
#############################################################
# example config for SSL and Non-SSL hosts in the same config
# main server is an SSL one...
#

ServerName ssl.fictional.co
ServerType standalone
ServerAdmin www@ssl.fictional.co
User www
Group www
Port 443
Listen 443
Listen 80
SSLVerifyClient 0
SSLVerifyDepth 10
SSLCertificateKeyFile /www/certs/ssl.fictional.co.key
SSLCertificateFile /www/certs/ssl.fictional.co.cert
SSLCACertificateFile /www/certs/CA.cert

#############################################################
# Note: The following directives are only required if session
# cacheing is enabled (the default from 1.17). To disable
# cacheing, make sure the following is set in apache_ssl.c
#
#define CACHE_SESSIONS FALSE

SSLCacheServerPath /www/bin/gcache
SSLCacheServerPort /www/cache/ssl.fictional.co.cache.socket
SSLSessionCacheTimeout 300

# end conditional section

76
Other security measures

DocumentRoot /www/hosts/ssl.fictional.co/docs
TransferLog /www/hosts/ssl.fictional.co/logs/access.log
SSLLogFile /www/hosts/ssl.fictional.co/logs/ssl.log
ErrorLog /www/hosts/ssl.fictional.co/logs/error.log
PidFile /www/logs/httpsd.pid

# and a non-SSL one...

<VirtualHost www.fictional.co:80>
SSLDisable
Port 80
DocumentRoot /www/hosts/www.fictional.co/docs
TransferLog /www/hosts/www.fictional.co/logs/access.log
ErrorLog /www/hosts/www.fictional.co/logs/error.log
</VirtualHost>

# and another SSL one... (this one does client-cert

# authentication)

<VirtualHost another-ssl.fictional.co:443>
Port 443
SSLVerifyClient 2
SSLVerifyDepth 10
SSLCertificateKeyFile /www/certs/another-ssl.fictional.co.key
SSLCertificateFile /www/certs/another-ssl.fictional.co.cert
SSLCACertificateFile /www/certs/another-CA.cert
DocumentRoot /www/hosts/another-ssl.fictional.co/docs
TransferLog /www/hosts/another-ssl.fictional.co/logs/
access.log
SSLLogFile /www/hosts/another-ssl.fictional.co/logs/ssl.log
ErrorLog /www/hosts/another-ssl.fictional.co/logs/error.log
</VirtualHost>

Here is a 15-minute procedure (for testing only!) to set up an SSL-aware Apache web server
under /usr/local/apache/ and using mod_ssl. This procedure provides you with some
hands-on experience in setting this up before you apply this knowledge to your main server.

1. Fetch and extract the distributions of Apache, mod_ssl and OpenSSL;.

GET: http://httpd.apache.org/dist/httpd/apache_1.3.29.tar.gz
GET: ftp://ftp.modssl.org/source/mod_ssl-2.8.16-1.3.29.tar.gz
GET: ftp://ftp.openssl.org/source/openssl-0.9.7c.tar.gz
$ gzip -d -c apache_1.3.29.tar.gz | tar xvf -
$ gzip -d -c mod_ssl-2.8.16-1.3.29.tar.gz | tar xvf -
$ gzip -d -c openssl-0.9.7c.tar.gz | tar xvf -
2. Build OpenSSL:
$ cd openssl-0.9.7c
$ ./config
$ make
$ cd ..
3. Build and install the SSL-aware Apache:
$ cd mod_ssl-2.8.16-1.3.29
$ ./configure \
--with-apache=../apache_1.3.29 \
--with-ssl=../openssl-0.9.7c \

77
 Chapter 6: WebNative Security

--prefix=/usr/local/apache
$ cd ..
$ cd apache_1.3.29
$ make
$ make certificate
$ make install
4. Clean up:
$ rm -rf apache_1.3.29
$ rm -rf mod_ssl-2.8.16-1.3.29
$ rm -rf openssl-0.9.7c
5. Fire up your SSL-aware Apache and try it out replacing local-host-name with the
fully qualified domain name (FQDN) of your web site which you entered at the make
certificate step above.
$ /usr/local/apache/bin/httpd -DSSL
In your browser type:
https://local-host-name/

The one thing to note when using SSL is that it will require more processing power then reg-
ular http because all transactions must be encrypted/decrypted.

Intrusion detection

Now that you have secured your network and servers, how do you detect if anyone has
attempted or worse yet succeeded in breaching your defenses? The first thing you must do
is check your logs on a regular basis. The logs from your firewall as well as the ones from
your server are very useful in providing a trail of evidence. If you are going to use them in
court though, you must ensure that they are on a file system that is secure and that you can
prove that they have not been edited — backing them up to permanent or change-protected
media is a good idea.

There are also several applications that can help you such as Tripwire, Snort and Honey
Pots. Honey Pots are essentially systems that are placed in your DMZ which have only basic
security, but no real useful data on them. Their only purpose is to attract the attention of
would-be hackers and lure them in. You can then track and log their progress for later pros-
ecution.

Tripwire software is a tool that checks to see what has changed on your system. The pro-
gram monitors key attributes of files that should not change, including binary signature,
size, expected change of size, etc. Tripwire is originally known as an intrusion detection
tool, but can be used for many other purposes such as integrity assurance, change manage-
ment, policy compliance and more.

Snort (aka The Piggy) is a comprehensive packet-analyzing intrusion-detection system

(IDS). And ACID is a PHP-based analysis engine to help you search and analyze your IDS
logs.

This subject is very complicated in itself and further research is an exercise best left to the
reader.

78
 Links and other reading

Links and other reading Apache Cookbook. By Ken Coar, Rich Bowen, November 2003, ISBN: 0-596-00191-6,
O’reilly Publishing — this is a must have for anybody serious about Apache web servers. It
provides many useful examples for both everyday and complex configuration issues.

UNIX System Administration Handbook. By Evi Nemeth, Garth Snyder, Scott Seebass
and Trent R. Hein, Third Edition, ISBN: 0130206016, Prentice Hall. See chapter 21 for
security, but the book in general is an excellent resource.

Apache
• Apache-SSL:
http://www.apache-ssl.org
• mod_ssl for Apache:
http://www.modssl.org/
• OpenSSL:
http://www.openssl.org/
• Tutorial on how to setup Apache SSL
http://www.onlamp.com/pub/a/apache/excerpts/chpt13/index.html
• Federal Information Processing Standards Publication 181 – Password Generation
http://www.itl.nist.gov/fipspubs/fip181.htm
• An extensive selection Whitepapers you can purchase
http://www.bitpipe.com/
• Demystifying CISCO Access Control Lists
http://www.networkcomputing.com/907/907ws12.html.1
• High-end firewalls, VPN, routers, etc
http://www.cisco.com

Tripwire software
• Open Source: http://www.tripwire.org
• Commercial: http://www.tripwire.com

Snort — open source intrusion detection

http://www.snort.org

Analysis Console for Intrusion Databases (ACID)

http://acidlab.sourceforge.net/

A great site for information on networking technology and security:

http://www.networkcomputing.com/

Signing authorities
• Thawte Consulting at http://www.thawte.com/html/RETAIL/ssl/index.html
• Verisign at http://digitalid.verisign.com/server/apacheNotice.htm
• CertiSign Certificadora Digital Ltda., at http://www.certisign.com.br
• IKS GmbH, at http://www.iks-jena.de/produkte/ca/
• BelSign NV/SA, at http://www.belsign.be
• Verisign, Inc. at http://www.verisign.com/guide/apache

79
 Chapter 6: WebNative Security

• TC TrustCenter (Germany) at http://www.trustcenter.de/tc-server

• Deutsches Forschungsnetz at http://www.pca.dfn.de/dfnpca/certify/ssl/
• 128i Ltd. (New Zealand) at http://www.128i.com
• Entrust.net Ltd. at http://www.entrust.net/products/index.htm
• Equifax Inc. at http://www.equifaxsecure.com/ebusinessid/
• GlobalSign NV/SA at http://www.GlobalSign.net
• NetLock Kft. (Hungary) at http://www.netlock.net
• Certplus SA (France) at http://www.certplus.com
• GeoTrust Inc. (USA) at http://www.freessl.com
• register.com (USA) at http://commercelock.register.com
• lanechange.net (Canada) at http://www.lanechange.net/#server certs
• KPN Telecom (The Netherlands) at http://certificaat.kpn.com/
• Tier Networking (USA) at http://www.tier-networking.com/sslcerts/
• ipsCA (Spain) at http://certs.ipsca.com/FreeCertsForApacheSSL/
• CAcert (Australia) at http://www.cacert.org/
• Comodo CA (USA/UK) at http://www.instantssl.com/

80
 Option 1: One big raid, one big WebNative Venture volume

Chapter 7

Archiving to disk using the WebNative Suite

Many customers are choosing to maintain large archives on spinning disk rather than on
removable media. The main driving factor in this trend is that disks have gotten consider-
ably cheaper, tape libraries have not followed suit, and maintaining files you may reuse
online gives easier, quicker access. This chapter describes some of the different strategies
that can be employed to archive to disk using the tools included in the WebNative suite, and
give some ideas about why you might deploy them.

Before embarking on a system that involves only online archive, please be aware that you
must independently ensure that your system is backed up. This means a regular process that
either backs files up to removable media that is taken off site, or using a network system to
back up to a different physical location. Regular tests to ensure that you can recover from
your backups should be scheduled and performed.

The first step to implementing an archive to disk strategy is determining your company’s
needs. Often companies will implement an archiving-to-disk regime that is an exact mirror
of their previous archive-to-tape system, including all its limitations and quirks. While this
is certainly possible, and sometimes appropriate, more often that not changes can be made
to improve your overall efficiency. Before the different strategies can be evaluated, deter-
mine how much data needs to be “archived” each year, and how much of that data is ever
accessed again after archive (either in whole or in part). Also evaluate how quickly and eas-
ily data on archive needs to be accessed.

Option 1: One big raid, One option is to keep all work that might be reused in place in the production area. This
one big WebNative means all the data on a fast RAID system and leaving it in place where it was created as long
Venture volume is it might be reused, either with one WebNative Venture volume or several, depending on
access and organization needs. This scenario is appropriate for customers that have data that
is accessed often, but has a limited longevity. This system also assumes a skilled and disci-
plined production crew that can be relied on to manage the production files in a consistent
and regimented manner.

An example of a customer that might deploy this sort of system would be a Print-On-
Demand house servicing a vacation cruise line. Customers are likely to request data sheets
about any of the cruises available, some of the data (such as boat descriptions) is relatively
static and other data (such as special package pricing) changes a lot, but old data (such as
packages available in 2005) does not need to be maintained. This sort of customer wants
immediate access to all the data that is relevant on the server, and wants to be able to auto-
matically feed the press with it as soon as a customer requests it. Refreshing RAID hardware
on a regular schedule will be sufficient to solve problems with growth of files.

81
 Chapter 7: Archiving to disk using the WebNative Suite

Option 2: One raid, one In the case where production is controlled, and jobs get reused relatively often, it may make
JBOD (or old raid), two sense to have a “live” production area and an equally accessible “archive” area on slower,
or more venture cheaper disk. This sort of setup is appropriate where a shop has an established workflow,
volumes, operator production staff are disciplined and used to controlling jobs from the desktop. In this setup,
control there is one (or more) production volumes, and one (or more) non active, but equally acces-
sible volumes. Migration between active and non active production can be as simple as an
operator selecting the job folder (with a trigger button) when the job is “finished.” Migra-
tion could be more complicated, such as a trigger that automatically moves jobs that have
not been accessed in a certain amount of time, or a scheduled move where all jobs are cata-
loged by customer/month/year after they reach a certain age.

An example of a shop that might prefer this setup would be an active, long-established pre-
press shop with a large stable of customers. Much of the knowledge about customer behav-
ior (for example, how much reuse is likely) lies in the minds of the production people, and
this setup allows them to control the environment in what they find easy and familiar. The
advantages of this setup is that most work that is likely to be reused is already in produc-
tion, and less likely to be used jobs are still easily available, but they do not impact every-
day searching and navigation with their size.

If you’re interested in a system like this, be sure and read about the WebNative Venture
movetree Action, beginning on page 155.

Option 3: One The scenario that most mimics traditional archive-to-tape is a setup, where the fast produc-
production area, one tion area is “live” and the other disk is essentially a read only, retrieve-on-demand storage
strict archive area, strict area. This is quite easy to implement with WebNative using Triggers and Actions. A trigger
migration policies to move to the archive area can be set up (and usually applied to a button with a Portal tag).
It is trivial to restrict who can archive, and if you wish you can easily implement an
approval process here. For example, most users’ requests to archive could simply execute a
Trigger to send a mail with a hot-link to a manager. The manager can choose to archive
(which actually does the move in their case) or not. The other volume has no access privi-
leges (but is searchable and all previews, mviews, metadata, etc. are available). A button
that triggers a copy back to the production volume (either to its original location or with a
path mapping, via a custom Action) allows users to begin reusing the job immediately.
“Trigger Set Configuration” beginning on page 147 and “Trigger Set Customization” begin-
ning on page 167 provide more information about WebNative Triggers and Actions.

Another option is to use the WebNative Portal Asset Feature Request module, which
requires administrative approval for restoration requests before the files are placed in a
retrieval area. More complex systems (for example, versioning files that are archived again
after being used again) are also possible to implement using Triggers and Actions if desired.

An example of a shop that would use this is one with a large, floating production staff. Only
the person in charge of the job would be able to sign it off for archive (generally when it is
approved) and a complete record of all produced jobs is maintained. Note that it is not diffi-
cult to implement Option 2 and 3 at the same time, with some users given large amounts of
control and other users very little by using WebNative permissions and Permsets. You can
also choose to make the migration to archive more programmatic (by date, access, etc.)
rather than by human control if you wish. Retrieval from archive can also be controlled. For
example, you might want to pass all non in-house images that are more than a year old by

82
 Grooming

Legal to ensure that rights have been checked. The flexibility of metadata-driven Triggers
and Actions allow you to make this as controlled as you wish.

Grooming Note that most disk archives will tend to grow over time (the one exception we know of is a
customer that prints funeral cards, as most people tend to die only once). There needs to be
a program in place to consistently refresh hardware to keep up with this growth. Hardware
historically has increased in storage size and processor power faster than the stored data
grows. It is also good to consider that some data is no longer worth maintaining. For exam-
ple, it is not necessary to maintain jobs for customers that are no longer in business. In other
cases, a particular job may no longer be usable, but some elements (such as a product shot)
may be re-usable. Often the most important issue is to ensure that you have sufficient orga-
nization or metadata to actually be able to find the correct job in your archives.

83
 Chapter 7: Archiving to disk using the WebNative Suite

84
 What does a database provide?

Chapter 8

WebNative Venture overview

When designing WebNative® Venture, Xinet engineers wanted to preserve those character-
istics of WebNative which make it easy to use and easy to administer, while adding the
functionality that only a complete database could bring. One of the challenges Xinet engi-
neers faced was implementing a solution that would not require customers to hire database
administrators or programmers.

WebNative Venture introduces a database that runs beneath WebNative, completely inte-
grated within the software to allow much faster searching of large file repositories, the ability
to customize fields for metadata, and the possibility to automate tasks using Triggers and
Actions.

What does a database What features does adding a database underneath WebNative provide? First of all, you’ll be
provide? able to search for files much more quickly whenever there are large amounts of data. In pre-
vious WebNative releases, searching through large amounts of data was slow, because as it
looked for data, WebNative had to “walk” through the entire file system. Database search-
ing will take much less time because all the information about files is now stored in readily-
accessible tables. With a database as the searching tool, WebNative users will also be able
to initiate more complicated searches and search for multiple targets simultaneously.

The WebNative Venture database also opens up broader metadata searching than was previ-
ously possible. In fact, you can configure the database to search for any metadata you care
to add. This can be good for you, in-house, or when you are working with particular cus-
tomers who may have special needs. The metadata fields are very flexible, so you can cus-
tomize searching very easily. You can also control which users can see the metadata that’s
associated with files and the way that users are allowed to interact with this information.
Can they change the metadata fields? If so, how? By typing in new information, clicking
buttons, or using pop-up menus?

WebNative Venture also automatically tracks files as well as keeping a historical log of
what activities have taken place on the server. Because Xinet software provides the file ser-
vice, the print spooling system, the OPI system, and the web service, it know everything
that happens to the files on the server, and WebNative Venture automatically logs the infor-
mation into its database. From those logs, you can see who deleted a particular file, find out
how many times a file has been used or saved in other formats, etc.

How does WebNative On each of your existing WebNative volumes, you can choose whether or not you want the
Venture work? WebNative Venture database to track the data that’s on the volume. If you do, all the infor-
mation about each file on the volume will be read into the database. This includes the cur-
rent keywords, embedded comments, and other and XMP metadata. You can also add
additional categories of information that you wish the database to record.

After you turn on the database for a WebNative volume, the database records everything
that happens to the files in that volume. It notes whenever files are changed or edited, when-

85
 Chapter 8: WebNative Venture overview

ever they are moved or their names are changed, or whenever anyone makes copies of
them.

WebNative Venture was designed so that it doesn’t need to rely upon a “check-in” and
“check-out” system because Xinet didn’t want to require that a person sit in front of the
database to ensure that it worked properly. Instead, the database runs in the background
silently gathering data for later use without interfering with your production workflow.

What database does WebNative Venture comes bundled with a commercially-licensed version of the MySQL
WebNative Venture use? database.

Xinet looked at and tested many other databases, and found that the MySQL database per-
formed and scaled very well. In addition, its originators could provide Xinet engineers with
source code. This allows Xinet to distribute a modified version of the database within Web-
Native Venture which is very easy to administer. Xinet engineers have been able to ensure
that the MySQL database installs and configures automatically when you install WebNative
Venture. You don’t need to install a separate complex database package nor spend a great
deal of time configuring it.

Xinet Technote 137, available from www.xinet.com, provides details about the kinds of
information WebNative Venture stores in its database and the internal structure of tables
through which the database stores information. While most users won’t need to understand
these details, the instructions in this Technote will allow anyone who wants to write supple-
mental programs that integrate with the WebNative Venture database to do so. In addition,
the information should make the task straight-forward for those who want to copy data from
the WebNative Venture database to use in another system, or bring in data from an existing
system. “Importing data into WebNative Venture” on page 189 and “Using the export
function in WebNative Venture” on page 201 also provide information.

How do you enable the Subsequent chapters contain details about setting up and running the WebNative Venture
database? database. The basic steps include:

1. Turning on the database for WebNative volumes.

2. Adding new data fields or modifying existing fields to make the database more efficient
for you and your customers.
3. Creating Data Field Sets to more easily manage Data Fields.
4. Setting up templates that display subgroups of fields so that all users won’t see every
data field.
5. Assigning templates to users and further constraining the fields that individual users
see.
6. Establishing Actions and Trigger Sets.

86
 Volumes setting summary

Chapter 9

WebNative Venture statistics and operation — the

Database tab

The Database GUI shows details about what’s stored in the database, statistics about data-
base performance, and information about where programs and data files are stored. The
Database GUI also allows you to enable the database on a per-WebNative-volume basis,
to regulate the daemon behind the database, and to start and stop the database.

Volumes setting Clicking on the Volumes link in the orange bar underneath the Database tab presents the
summary Volume Settings summary shown in Figure 31. It is the default view when you click the
Database tab, presenting database-related information about all WebNative-enabled vol-
umes on the server.

This link opens an This link opens an This link opens an This button will allow
interface where interface where you interface where you to login as a user
you find statistics establish parameters you establish other than
about data within for how the WebNative details for back- “nativeadmin.” This
and users of the Venture ing up the is useful when you
database. It also daemon, dblogd(1M), database. want to see the effects
This link leads to a will update the data-
series of subtabs
where you establish
which
WebNative volumes
will enlist the database

Clicking either of these

opens an interface
which allows you to
The headings in the change any
table summarize data- of the settings summa-
base-related attributes rized here for a particu-
for
WebNative volumes

A 3 means the feature

has been enabled. This column only
appears when servers
are licensed for WebNa-
tive Venture with Video
Support

FIGURE 31. The Volume Settings summary

The following section, “Enabling the database on volumes” describes what each attribute
in the table governs.

87
 Chapter 9: WebNative Venture statistics and operation — the Database tab

Enabling the database on WebNative Venture uses the usual WebNative mechanisms to deliver search results. It will
volumes first look through the database for answers to queries, and if it doesn’t find answers there, it
will then look through the file system. This will all be transparent to WebNative users. You
may choose the WebNative volumes for which you enable the database. You may not want
to turn on the database for small volumes where search speeds are already fast enough, or,
for volumes without metadata, since the time your system will spend syncing volumes
wouldn’t bring great improvement to the speed of your search results.

To enable the database:

1. If you’re not already seeing the Database GUI, click on the Database tab. Then, click
the Volumes link, then either the Edit button at the top of the display or one of the Edit
links for a particular volume in the right-most column. You should see an interface
similar to the one in Figure 32.

FIGURE 32. Setting database options for volumes

2. Use the Enable Database pop-up menu to establish which volumes you are interested in
configuring. You may choose between No Volumes, All Volumes, or Selected Volumes.
Selecting No Volumes (after clicking Submit) will turn-off the database for all volumes.
Selecting All Volumes (after clicking Submit) will enable the database and apply the
same options for what it stores to all volumes.
If you’re using the database on Selected Volumes, you must explicitly turn on the
database for each volume. Select the volume in the Web Volume pop-up list. Then, click
the Enable Database box.
3. Use the checkboxes to specify what kinds of previews will be stored in the database. A
brief description follows. Keep in mind that if you’ve turned off a user’s ability to
access particular previews, he or she won’t be able to make use of the settings here.
(Step 3. on page 38 explains these settings.) For the database, you may choose among:
• Store Small Web Preview
Small Web Previews are the previews which, by default, users see in WebNative’s
“Short View.” See page 38 for more information about these previews.

88
 Enabling the database on volumes

• Store FPOs
Turning on this option makes FPOs available to users, even if the file has been
archived. The search engine can look in database tables rather than transversing the
file system to find the FPOs. On the other hand, it also means that your database data
will consume more disk space. If you have limited storage, you might want to bal-
ance your use of this option. (The WebNative Info portion on the GUI (the Database
link takes you there) tells you how many FPOs are stored in the database. Multiply-
ing that number by the resolution at which FullPress is generating FPOs will tell you
how much space you’re using.) On UNIX systems, by default, the FPO table is lim-
ited to storing 16 x 4 (64) gigabytes of data. Windows systems are limited to the
amount of space available in the file system. If you need to increase the table’s stor-
age capacity, please call Xinet Technical Support for details.
• Store Large Web Preview
Large Web Previews are the larger GIF or JPEG previews whose resolution you
determine in the Web Options portion of the FullPress GUI. They are typically
smaller in file size than FPOs and do not contain OPI comments. Be sure to turn this
on for any volume from which clients will be dragging and dropping images. (“Notes
about configuring the WebNative server for Drag and Drop” on page 17 provides
more information.)
• HSM syncs (Skips data fork reads)
The HSM Sync option should be used for anyone using an Hierarchical Storage Man-
agement (HSM) system. Turning it on will prevent data from being staged when Web-
Native Venture syncs the database. By default HSM Sync will be turned off.
• For more information about interaction between WebNative Venture and HSM file
systems, refer to Xinet Technote 183, available at www.xinet.com.
< > • Store Multipage PDF previews
Previous Next Storing multi-page PDF previews allows users to click through small previews of
page page pages within multi-page PDF and Microsoft Office files1 stored on the volume, as
well as preview larger spreads, just as they can with InDesign and QuarkXPress doc-
uments. (Unlike previews of QuarkXPress and InDesign files, the PDFs and
Microsoft Office files do not have to first be saved with a WebNative extension or
plug-in in place.) Without this option enabled, users will only see previews of the
first page of multi-page PDF and/or Microsoft Office files. Enabling this option will
use more database resources. You should also enable Store Small Web Previews and
Store Large Web Previews when you use this option.
• Store Movie Key Frames
This option appears only when a server has been licensed for WebNative Venture
with Video Support. It enables the Video Support plug-on for WebNative Venture.
Please see the Xinet WebNative Venture with Video Support Administration Guide
for more information about this feature.
4. Click the Submit button to register the settings and begin a sync of the new volume.

For background information about what happens in the database when you add volumes
and information about synchronizing volumes, refer to “Database synchronization” on
page 243.

1. Xinet support for Microsoft Office file previews requires that you install openoffice2.1 on your WebNative server. For your convenience, Xinet pro-
vides a copy of these binaries in the Help/Downloads area of the Xinet web site, www.xinet.com.

89
 Chapter 9: WebNative Venture statistics and operation — the Database tab

Database administration Clicking on the Admin subtab within the orange Database tab presents the GUI shown in
Figure 33.

Statistics about
database
performance are

Information
about parts of
the file
system used by

Information
about
memory & con-

Tells whether the

File Name table
has been
Indexed. You

These buttons
allow you to start
and stop MySQL.
Stopping the data-
base does not stop If you are running the database on a dif- These buttons allow you to change
ferent server, use this pop-up list to give the locations where WebNative Ven-
the database access to the WebNative ture writes and stores data.

FIGURE 33. The primary administrative database GUI

What the fields in the The Database GUI is where you’ll look for information about how your database is growing
Database GUI show and how it’s performing. Here’s what the various fields in this GUI mean:

Server Info
• Status
This shows whether or not MySQL is currently running.
• Version
This shows the version of MySQL which is running.
• Uptime
This shows (in seconds) how long the current session of MySQL has been running. The
number goes to 0 each time the database stops.
• Threads
This indicates how may requests are hitting the database at any moment, or in other
words, how many users and processes are currently requesting information from the
database.
• Queries
Logs the number of queries made to the database since the last time it was restarted.

90
What the fields in the Database GUI show

• Slow Queries
Any query which takes a long time to complete gets logged here. By default, that will be
any query taking longer than 10 seconds. The number in this field indicates slow queries
in the time since the database was last restarted.

Directories
• Base Directory
This indicates the directory where WebNative Venture and MySQL were installed. On
UNIX systems, this will be /usr/etc/venture. On Windows systems, it varies, depending
where you installed the software. The default location is
C:\Program Files\Xinet\Venture.
• Data Directory
This indicates the directory where the tables containing data for WebNative Venture gets
written. The default directory for UNIX installations will be /usr/etc/venture/data/web-
native and on Windows systems C:\Program Files\Xinet\Venture\Data\WebNative. Most
administrators will want to change this directory to one with more adequate storage
space, using the Edit button to the right.
• Temp Directory
The database will use the directory shown here to write intermediate results of its activ-
ities. By default, this will be /tmp/ on UNIX systems and on Windows systems, the
default temp directory, e.g., C:\winnt\temp. You may change this directly, using the Edit
button at the right.

Memory and Thread Limits

• Memory Buffer Size
This refers to the amount of RAM to be used by the mysqld daemon when processing
events. The amount of available RAM for a server will determine the best value for this
field. If a machine is to be used primarily by WebNative Venture users, and FullPress is
not already taxing the machine, then you can set this value to up to 25% of the total
available RAM. For example, if a server has 2GB RAM, the value in this box can be up to
500MB. If a machine is used for both FullPress and WebNative Venture operations, 10%
of the total available amount may be a better choice—a value of 200MB would be set in
that field.

It is important to note that this value is most important during heavy periods of memory
usage, such as during the creation of a FullText index.
• Maximum Concurrent Threads
This is a configureable option only on Solaris servers. (Thread handling is optimized by
the OS on other platforms.)

The maximum allowed number of concurrent threads, or simultaneous database opera-

tions, can be set in this field. A general rule is to use the number of CPUs times two; a
machine with two processors can have a value of up to four concurrent threads. The
value describes the maximum number of non-locking operations performed at once;
many Venture operations open tables for writing, and therefore this value will not apply
during those situations.

91
 Chapter 9: WebNative Venture statistics and operation — the Database tab

File Table FullText Index Searching

On new systems, the Add Index button can be used to add a FullText index to the WebNa-
tive Venture file table. This will increase the speed of searches done on WebNative Venture-
enabled volumes. If you are configuring WebNative Venture for the first time, and have not
yet enabled any volumes, you can easily add the index by clicking this button. It will only
take a few seconds to add the index.

Alternately, if you are managing an existing installation and wish to add an index, you
should use the dbmgr -buildfulltextindex command which builds the index in the back-
ground without interrupting database activities. See the dbmgr(1M) man page for details.
Keep in mind that building an index on a large WebNative Venture database can take a very
long time—in fact, it may take several days to create an index of a very large file table, say
one containing over one million files.

Maintaining a file-table index can slow down systems very slightly and may cause the table
to grow quite large over time. In some instances, a system administrator may choose to
remove the index. The Drop Index button will remove the index from the database.

Access Control List

If you are running your database on a different server than your WebNative server, use the
Access Control List pop-up menu to select the ACL which provides that server access to the
WebNative server. The choices which appear in the pop-up menu are those ACLs which
you previously established using the FullPress GUI on the WebNative server. They provide
access to the server from specific remote machines.

If you do not see the choice you want in the list:

1. Go to the FullPress GUI and set up a new ACL.

The default choice localhost ONLY is the correct setting when the database and
WebNative are installed on the same machine.
2. Click the Save button to register any change you make.

File Transaction Logging

Establish parameters for storing file transaction logging by setting the largest number of
transactions you want to save and the number of days you want to keep them. WebNative
Venture will use both parameters in managing the size of your log. Most sites will probably
want settings that keep information around while a job is actually in production. Keeping
more information will certainly increase the size of log files.

Stopping and restarting the database

You can stop MySQL without affecting operations which depend on WebNative and Full-
Press. WebNative Venture will stop logging activities on your file system during the period
while it is shut down. Then, upon restarting, the database daemon will check for changes
and bring the database up-to-date.

92
What the fields in the Database GUI show

To stop the database:

1. Click on the Database tab or the Database button so you are viewing the GUI shown in
Figure 33.
2. Click on the Stop Database button.
3. Confirm that you want to stop the database.

To restart the database:

1. Click on the Database tab or the Database button so you are viewing the GUI shown in
Figure 33.
2. Click on the Restart Database button.

Changing the data and temp directories

WebNative Venture provides a convenient way for you to change the locations where it
stores data and temporary files. When you change these locations, all of the tables contain-
ing your old data will be preserved and moved to the new locations. To change the location
of these directories:

1. Create a new directory on the file system into which the database will be moved.
2. Click on the Database link so you are viewing the GUI shown in Figure 33.
3. Click on the Edit... button for the Data Directory or the Temp Directory. The dialog box
shown in Figure 34 will appear.

FIGURE 34. Changing the Data or Temp directory

4. Type the complete path for the new directory.

5. Click on the Set Directory button.
6. Click on the Close button.

93
 Chapter 9: WebNative Venture statistics and operation — the Database tab

WebNative Venture The Stats subpanel presents statistics about the database and server, as shown in Figure 35:
statistics

FIGURE 35. Database and server statistics

The subpanel is divided into two portions:

WebNative Info
• Users
This number reflects the number of different WebNative users who have written infor-
mation in the database.
• Files
This number indicates the number of files which currently have records in the database.
Every file in a volume for which WebNative Venture has been enabled will have a
record. The number of records therefore increases each time a new file is added. Besides
files currently online, the number reflects files once-online but now-deleted and files
which were once-online but now-archived. Each record indicates the current state of the
file. In the case of a file that was moved from online to archive, and then restored, there
will be two records; but only one record will be marked as online.
• Archived Items
This number indicates the number of files that the database registered as archived. When
viewed through a browser, the files will be marked with either red, green or gray triangles.
• Stored Small Web Previews
To provide more useful database search results, you can configure WebNative Venture
on a per-volume basis to actually store previews in the database. This number shows the
number of entries for which thumbnail previews have been stored.
• Stored FPOs
This shows the entries for which FPOs have been stored.
• Groups
WebNative users can be put in groups that share volume parameters. This number reflects
the number of different WebNative groups who have written information in the database.
Refer to “Creating and editing groups” on page 53 for more information about groups.
• Folders
This reflects the number of folders which currently have records in the database. The
number increases over time, similar to the way the file number increases.

94
 Configuring the database daemons

• Archived Folders
This number reflects the total number of folders that have been archived on the server.
• Stored Big Previews
This number shows the number of entries for which larger web previews have been
stored.
• Items with Data Fields
This indicates the number of files which have data fields. Files without embedded meta-
data will not have information to be stored in data fields. These fields are comprised of
XMP metadata, as well as any custom data you ask WebNative Venture to track.

Server info

This portion presents the same information seen in the Admin subpanel, as described in
“Server Info” on page 90.

Configuring the database WebNative Venture depends on two software daemons and one program to keep informa-
daemons tion up-to-date and to communicate with MySQL:
• The dblogd(1M) daemon is responsible for sending information from FullPress and
WebNative to MySQL.
This daemon is rather like the FPO daemon that FullPress uses. The daemon
automatically gets information from various programs on the file server and print-
spooling system, as well as from WebNative, and then it logs this information into the
database.
In the same way that FullPress generates its FPOs automatically, without the user having
to initiate this process, WebNative Venture database processing occurs automatically
and in the background. Because all of the activities that are taking place on the server
are happening within the integrated FullPress/WebNative system, the software can help
keep the server’s processing loads balanced, so work won’t slow down. This means that
when your system gets busy and as a result, a lot of database processing needs to happen
on the server, it won’t happen in a way that slows your production down. The database
processing system will wait, letting more important interactive processes finish, and
only log information at a rate that won’t overload your server. You’ll never find your
server making too many FPOs at once or logging in too much data at once.
For more information about dblogd(1M), refer to “Scheduled syncs” on page 247 and
the dblogd(1M) manual page.
• The mysqld daemon provides the Database Management System (DBMS). It’s responsi-
ble for inputting and outputting information from the database. It handles requests for
accessing information that’s in the database and also responds when another daemon or
program wants to write information to the database.
• The syncvoltodb(1M) program makes sure that the information stored in data tables
reflects changes in the FullPress and WebNative file system. The dblogd(1M) daemon
which watches for these changes prompts the syncvoltodb(1M) program.

95
 Chapter 9: WebNative Venture statistics and operation — the Database tab

Figure 36 shows the relationship between these components.

File server WebNative

dblogd Sends u
pdates fr
FullPre om
Calls synchvoltodb ss & We
bNative Manages the input and
when necessary mysqld
output of data from the
database
DATABASE

Manually updates
complete volumes
syncvoltodb

FIGURE 36. Relationship between dblogd(1M), synchvoltodb(1M) and mysql.

The Daemon subpanel of the Database GUI provides a way for you to change the configu-
ration of the dblogd(1M) daemon and syncvoltodb. Clicking on the
Daemon link under the Database tab presents the subsection shown in Figure 37.

FIGURE 37. Configuring the database daemon

Scheduling database verification

Periodically, WebNative Venture, via a synchronization performed by dblogd(1M), checks

to make sure that the information in the file system matches the information in the various
database tables. There are a number of circumstances, for example, manual changes to the
file system in a UNIX shell, whereby changes to the file system might not otherwise be reg-
istered by MySQL. Because this synchronization is a somewhat CPU-intensive task, it is
best to schedule verification at a time when demands on the server are low. The actual time
it takes depends on whether FPOs are being stored in the database, and how many changes
have been made to files, since the procedure won’t bother with files that haven’t been modified.

96
 Backing up and restoring data

To change the verification schedule:

1. Using the Schedule Database Verification pop-up lists, select the time at which you
want verification to occur.
2. Check the days of the week upon which you want it to occur.
3. Click the Update button to register the changes you have made.

Controlling the flow of information to MySQL

WebNative Venture, via the dblogd(1M) daemon, will stop writing data to MySQL when the
file system is in danger of becoming full. Serious errors that announce this danger will
appear in FullPress AppleTalk log file, which you can view from the FullPress GUI. How-
ever, WebNative and FullPress will continue operation as normal, if this happens. The act of
logging information to MySQL will simply be suspended and will resume as soon as the
problem has been corrected. In such instances, you will see Status: Stopped at the top of the
Daemon GUI and a warning message will appear in the FullPress at_log (UNIX) or
at_log.wn (Windows) file. Once sufficient space has been allocated to the file system, the
dblogd(1M) daemon will write any changes into the database.

You can set the danger size for suspension of database activity. To set the size of reserved
disk space:

1. Type in a new number in the Suspend Processing When Disk Space Less Than field.
2. Click the Update button to register the change.

Backing up and restoring Scheduling backups

data
The Backup subpanel, shown in Figure 38, allows you to establish parameters about how
WebNative Venture backs up data stored in its database.

These pop-up lists

show backups
currently residing in
the backup location.

FIGURE 38. Backing up the database

97
 Chapter 9: WebNative Venture statistics and operation — the Database tab

WebNative Venture, like other SQL databases, stores information in tables. During database
backups, each table is put into read-only mode as it is backed up. Most tables are small and
won’t be read-only for long. However, larger tables can be read-only for some time, and for
this reason, it is best to schedule backups for times when system activity will be low.

Any errors encountered in backing up the database will be recorded in /var/adm/appletalk/

venture.log on UNIX systems and C:\Program Files\Xinet\FullPress\venture.log on Win-
dows systems.

To set up a backup schedule:

1. Click on the Backup subtab under the Database tab.

2. In the Backup Location box in the Backup GUI, provide the directory name (using the
full path) where you want to have the backups stored. Click the Save button afterwards.
When you do, WebNative Venture will create the directory on the server if it does not
already exist.
WebNative Venture with a blank Backup Location. When you choose the location, keep
in mind that a single full backup will be as large as the database itself. It’s a good idea to
chose a location that will be backed up to storage media frequently.
3. Using the pop-up lists and check boxes, establish schedules for making backups. There
are two varieties of back-ups: Full backups and Quick backups. A Full backup will
contain everything that’s stored in the database including all previews. A Quick backup
will contain everything, except previews.
You probably want to schedule Quick backups more frequently than Full backups. A
Quick backup might be used to fix a problem with a single table, e.g., the file table. If,
however, there were a general failure or corruption, you would restore a Full
backup.The backup directories, once written to the backup location, will be named
following these conventions:
wnv_fullbkup.yyyy.mm.dd
wnv_quickbkup.yyyy.mm.dd
The database has also been scheduled to periodically synchronize its data, as described
in “Scheduling database verification” on page 96. There is a lock to prevent verification
and backup from occurring at the same time. WebNative Venture will resolve scheduling
conflicts should they occur.
4. Type a number in the Max Old Full Backups box to establish the maximum number of
Full backups you want to store in the backup location at a given time. You may store up
to 100.
Establish a schedule for Quick backups and also, the number of backups you want to
keep concurrently. Once again, you may keep up to 100.
To register these changes (and possibly, depending on the number of backup copies that
are already stored, to clean out your backup directory), click the Save button at the
bottom of the GUI.
5. [optional] If you want to backup your system immediately, or override the established
backup schedule, use the Quick Backup Now! or Full Backup Now! buttons at the
bottom of the GUI.

98
Backing up and restoring data

Restoring backups

To restore database backups, you need to work from the command line with root (UNIX) or
Administrator (Windows) privileges. With each backup, WebNative Venture includes a
script within the backup directory intended to automate the restoration process. The script
will be called either RESTORE_QUICK or RESTORE_FULL on Unix systems and
RESTORE_QUICK.bat or RESTORE_FULL.bat on Windows systems, depending on
whether the directory contains a Full or a Quick backup. Here’s how to use the scripts:

1. Before you begin the restoration, consider whether or not you want to restore the
backup to its original location. The easiest way to determine the original location is to
check the Backup location type-in box in the Database/Backups subpanel of the GUI;
however, this involves an assumption that the location in that has not changed since the
backup you are restoring was made. If you know this to be the case, your answer is
there.
If you are unsure, go to the command line and look within the backup itself. Each
backup, among its list of files, contains a file called either quickrestore.sql or
fullrestore.sql. That file, which is written during the backup process specifically for
restoration purposes, shows the original backup location. Here’s an example of the first
few lines of such a file:
use webnative;
DROP TABLE db;
RESTORE TABLE db FROM "/export/database/backups/
wnv_quickbkup.2003.02.23";
DROP TABLE webnativeperm;

The third line shows the location of the original backup, /export/database/backups/
wnv_quickbkup.2003.02.23, in this example.
Determine your original backup location.
2. [optional] RESTORE_FULL and RESTORE_QUICK each assume that you want to
restore WebNative Venture tables to the original Backup location.
If you don’t want to restore the backup to that location, edit either the quickrestore.sql or
fullrestore.sql file, replacing each instance of the original backup location with the new
path and directory.
3. Run the restoration script, either RESTORE_FULL or RESTORE_QUICK:
UNIX:
# RESTORE_FULL
or
# RESTORE_QUICK

Windows:
# RESTORE_FULL.bat
or
# RESTORE_QUICK.bat

The script will run, prompting for several responses to which you should answer
affirmatively:
Xinet Webnative Venture Backup Restore...

99
 Chapter 9: WebNative Venture statistics and operation — the Database tab

Warning! This script will temporarily stop the mysql daemon and
restore the back up found in this directory overwriting the
existing database!

Are you sure you want to continue? [y/n]

Attempting to shutdown mysqld...

Shutdown succeeded!

Copying fulltext indexed file table...

Copy done!

Restarting mysqld...

Restarted!
4. The script will ask that you enter your MySQL password:
Running mysql client as user root to run fullrestore.sql...

Enter password:

Afterwards, it will complete the restoration process. The time it takes to restore the
backed-up database will vary, depending on the size of each table in the backup you’re
restoring. When the process is complete, you’ll see:
Restore Script Completed

Indexes, if necessary, will be created and any webdblogs that have accumulated while
the daemon was off will be processed.
5. Click on the Admin subtab of the Database tab. It’s a good idea to check that the
information reported there makes sense before assuming the backup was completed
successfully.
You may need to perform a few more steps, depending on such things as whether your
backup has been archived. For details, please refer to the syncvoltodb(1M) man page
and “Database synchronization” on page 243.

More information about The dblogd(1M) daemon’s main duty is reflecting changes to the file system in the WebNa-
the dblogd(1M) daemon tive Venture database. Here is how it happens:

1. A change is made on an AFP volume using normal Finder actions, through

WebNative’s File Manager, by uploading, or by using ksmv/kscp/ksrm.
2. A record of the event is placed in the /var/adm/appletalk/webdblog file (or
C:\Programm Files\Xinet\FullPress\webdblog).
3. The dblogd(1M) daemon watches the webdblog file for new events. If it finds one, it will
first determine if the event happened on a WebNative Venture-enabled volume. If it did,
dblogd(1M) will compose one or many SQL statements that will register the change in
the database.

100
More information about the dblogd(1M) daemon

4. The dblogd(1M) daemon sends the SQL statements to mysqld, which does the actual
change in the database.

After these steps, the change appears in WebNative Venture.

The dblogd(1M) daemon will also run two types of “synchronizations:”

1. The daemon will sync a directory that is browsed where the modification times are out
of date.
It will not sync any subdirectories.
2. The dblogd(1M) daemon will manage periodic syncs.

Details about the webdblog file(s)

All events are added to webdblog by Xinet's binaries (ksd, upload, ksmv, dtool, etc).

The dblogd(1M) daemon will mark events as done by setting a bit as on for each event.
Events are never removed from the file. Thus, the log file will fill up with processed events
over time.

The webdblog file can only hold about 1MB worth of events, in other words, around 10,000
events. When the log file is full, the file will be deleted. A new, empty webdblog file appears
and events are added to it. So. the file gets recycled as part of daily use. It’s normal to see its
file size change, growing from 0 to 1 MB in size, then returning to 0.

It’s entirely possible to have many events happen at once. This will add events to the file
more quickly than dblogd(1M) can process them. In that case, more log files get made. In
particular:
• First, the entire contents of webdblog are copied to webdblog.001.
• A new, empty webdblog file is made, and new events go into it as before.
• The dblogd(1M) daemon will read events from the 001 file, which has the oldest events.
• When it has processed all events in the 001 file, that file is removed;
• The dblogd(1M) daemon turns to the original webdblog file and processes those events.

If even more events are added at once, you may see webdblog.002, webdblog.003, etc. The
oldest events will be in 001. The next oldest in 002, then 003, etc. The webdblog file will
always have the most recent events. As the events are processed, the files are removed, and
the oldest events are processed first.

Therefore, it’s entirely possible to see:

webdblog
webdblog.003

The maximum number of webdblog files is 99. If you have more than that, then events are
happening and not going into WebNative Venture log files. This only happens when
dblogd(1M) is dead for a long time. When dblogd(1M) starts, it will get all the events in the
100 existing logs, but will not get any events that happened after those logs filled up. It’s
advisable to run a syncvoltodb(1M) to catch up with missing events.

101
 Chapter 9: WebNative Venture statistics and operation — the Database tab

The contents of the webdblog file are not text, but you can see what events are in it by run-
ning the program called printdblog.

You will find this program in /usr/etc/venture/bin on UNIX systems. The printdblog pro-
gram does not exist on the Windows platform.

If you need to see a particular webdblog file (say webdblog.003), run the following:
# printdblog -f webdblog.003

Running printdblog -help will show more usage options as well. For example, usage
says that events that have not yet been processed will have an asterisk in front them.

Unnecessary webdblog files

If for some rare reason you find webdblog files and you are not using WebNative Venture on
your server, you can stop the server from writing these log files by adding a file, called dis-
able.venture to the appropriate directory on your server:
UNIX:/var/adm/appletalk/
Windows:C:\Program Files\Xinet\FullPress\

Afterwards, delete any remaining webdblog files.

When does dblogd(1M) spawn child processes

What does it mean when you see 2 or 3 dblogd(1M) daemons running?

Normally, you will just see a single dblogd(1M) whose parent is process id 1. This is the
daemon process.

Every single new event found in webdblog merits a child dblogd(1M). So if 100 files are
added to a volume, 100 different dblogd(1M) daemons will be run (one after another, not
simultaneously) to process each event. They will all have different process IDs, and their
parent will be the original dblogd(1M).

The dblogd(1M) daemon also manages periodic syncs. When such a sync is going on, a new
dblogd(1M) process is made that is a child of the original dblogd(1M) daemon process.
This process will spawn its own children if events need to be processed. So you may see a
parent dblogd(1M), a child, and (briefly) a grandchild. Unlike daemons called to process a
single event, the dblogd(1M) that manages a periodic sync will stay alive during the entire
time it takes to do the synchronization.

There is one more case in which dblogd(1M) is run: when a listdir runs a sync on a direc-
tory. The dblogd(1M) done on a directory is done very quickly because it does not descend.
Full details on this type of sync can be found in “Syncs done while browsing” on page 247.

When is dblogd(1M) paused?

There are times when dblogd(1M) is set to not process events from the webdblog files, i.e.,
it is paused. Note that paused is not the same as stopped. The Daemon tab in the GUI will

102
More information about the dblogd(1M) daemon

show when dblogd(1M) has stopped, meaning the process is dead. It will not show when
the process has paused.

Here are some cases when dblogd(1M) might pause:

• During a userperms sync.
• During a periodic sync: dblogd(1M) is not paused. However, since dblogd(1M) manages
the sync process, it makes sure that all sync events happen at a different time than any
event in the webdblog file. In effect, event processing is on hold.
• During a backup (quick and full).
• During a sync run from the command line: dblogd(1M) is paused in this case.
• During a listdir sync: dblogd(1M) processes events as normal (listdir puts them into
webdblog).
• During a database move: dblogd(1M) is stopped. After the move is complete,
dblogd(1M) is restarted. The certain way to see if dblogd(1M) has paused is to read this
file: /var/adm/webnative/dblogd.conf (C:\Programm Files\WebNa-
tive\Admin\dblogd.conf), looking for these lines:
Paused=0
ForcePause=0

Paused will be set to 1 if dblogd(1M) is paused. The ForcePause option is irrelevant.

Do any synchronizations write events to the webdblog file?

Of the four types of syncs, only one writes events to the webdblog file. The others send SQL
directly to mysqld.
• sync from listdir: writes to the webdblog file.
• sync run periodically: writes SQL directly to mysqld
• sync run from the command line: writes SQL directly to mysqld
• sync run by userperms (a submit in the Volumes tab): writes SQL directly to mysqld

Running dblogd(1M) in debug mode

If an event is not being processed correctly (for example, a filename is changed on the vol-
ume and the change is not reflected in WebNative), you may be asked to run dblogd(1M) in
debug mode. This will show us the SQL statements composed by dblogd(1M) to handle the
event and other debugging output.

1. Kill dblogd(1M). Use dblogd -k to kill the process.

2. Run dbload(8) in debug mode:
dblogd -D >& /tmp/dblogd.out (UNIX)
or
dblogd -D 2> dblogd.out (Windows)
Adding an additional -a flag redirects the debugging output to at_log. For example:
dblogd -D -a&
3. Repeat the action that has not been processed correctly.
4. Stop the dblogd(1M) process.

103
 Chapter 9: WebNative Venture statistics and operation — the Database tab

5. Restart dblogd(1M):
/usr/etc/venture/bin/dblogd (UNIX)
or
C:\Programm Files\Xinet\Venture\Bin\dblogd.exe (Windows)

6. Send Xinet Technical Support (help@xinet.com) the debug file.

What to do if events are not getting into the database

Updating the database is the responsibility of dblogd(1M). If changes made on the file sys-
tem aren't showing up in WebNative Venture, dblogd(1M) is the first suspect.

Here are some possibilities to consider:

1. Many events happened at once (adding files, removing them, etc.) and dblogd(1M) has
not had time to process them all.
If this is true, then you will probably see multiple webdblog files. The number of
webdblog files should be declining, mysqld will be busy, and many child dblogds should
be running as each event is processed.
2. The dblogd(1M) daemon has died.
When this happens, no changes are registered at all. You can see if this is true by using:
ps -ef | grep dblogd (UNIX)
or
Task Manager (Windows)
or
by looking in the Daemon tab in the WebNative Venture GUI.
3. The dblogd(1M) daemon has paused.
This happens during a periodic sync and during manual syncs.
You can verify that dblogd(1M) has paused by looking at:
/var/adm/webnative/dblogd.conf (UNIX)
or
C:\Programm Files\WebNative\Admin\dblogd.conf
Paused=1 ForcePaused will be set to 1 if dblogd is paused.
4. The dblogd(1M) daemon is running, but the queries it is making are slow.
In this case, dblogd(1M) is spawning children to process events as normal, but it is
taking a long time for each change to register in the database. Use the mysqladmin
processlist command or check the Slow Query count in the Admin tab. It may be that
a particular type of event is being processed far too slowly.
5. Another query has “locked” crucial tables.
Use the mysqladmin processlist command. (See “Troubleshooting WebNative
Venture” on page 213 for more information.) Xinet has seen this happen with servers
running IRIX 6.5.18 (an IRIX bug).
6. The dblogd(1M) daemon is suspended due to lack of disk space.

104
More information about the dblogd(1M) daemon

7. The “event” is a non event. Typically, this happens on NFS or SMB mounts. See Xinet
TechNote 161: Keeping SMB/NFS Volumes in Sync for more details.

Settings preferences for WebNative Venture in the dblogd.conf file

Using the dblogd.conf file for setting WebNative Venture preferences

The dblogd.conf file contains important configuration information for WebNative Venture.
This section describes the various switches that can be used in that file.

The dblogd.conf file is found in the following locations:

UNIX:/var/adm/webnative/dblogd.conf
WindowsProgram Files\Xinet\WebNative\Admin\dblogd.conf

There are two kinds of settings in this file: the first kind can be modified by using the
nativeadmin GUI, while the other kind is set by editing the dblogd.conf file directly.

It is important to note that you should not edit the dblogd.conf file by hand unless you need
to add the options described later in this section, as any errors may prevent WebNative Ven-
ture from functioning properly.

SETTINGS WRITTEN TO THE dblogd.conf FILE BY THE nativeadmin GUI

The Daemon State section shows the amount of free space left on the disk containing the
Venture data directory, the running state of dblogd(1M) (paused/running) and the process
ID (pid) of the current master dblogd(1M) daemon. Even if you have configured no other
settings in WebNative Venture, these settings will exist in the dblogd.conf file.
[Daemon State]
Free Space=12345
Paused=0
ForcePause=0
pid=4012
Running=1

The WebNative Venture quick and full backup settings follow the Daemon State section.
This Backup section shows the path where backups will be stored, as well as the execution
schedule for both full and quick Venture backups.
[Backup]
Path=/raid/venture.backup
[FullBackup]
Day=Sun
Hour=0
Minute=0
Second=0
Count=1
[QuickBackup]
Day=Mon,Tue,Wed,Thu,Fri,Sat,Sun
Hour=0
Minute=0

105
 Chapter 9: WebNative Venture statistics and operation — the Database tab

Second=0
Count=1

The other group of settings that can be changed in the nativeadmin GUI determine number
of events to be stored in the Event table. There are two settings that work in concert to
determine when events will be purged from the database: the number of items to store for
each file, Volume History Size and the length of time (in days) to store the event. In the
example below, the settings were modified so that the oldest events will be purged once
there are more than 100 events per file, and only if they occurred more than 10 days ago.
[Volume History Size]
DEFAULT_FOR_ALL=100
[Volume History Time]
DEFAULT_FOR_ALL=10

SETTINGS ADDED TO THE dblogd.conf FILE BY USERS

Every event that happens on the file system or in WebNative is stored for each file in a Web-
Native Venture volume. The events are then revealed to users when they click the Detailed
History button inside an imageinfo screen.

While many of the events are useful—for example, a file’s create date or the time a high
resolution download occurred—others are not so important; the date a file was backed-up
by FlashNet, for instance, may not be useful unless you are using WebNative Venture to
track this data. By default, WebNative Venture will not log backup events to either the back-
upfile and backuppath tables, nor will those backup events be inserted into the event table
for tracking via Detailed History.

Should you decide to track these events, you can edit the dblogd.conf and add two flags that
tell WebNative Venture to store Backup events, as well as update the backupfile and back-
uppath tables. Not storing these events help to keep the size of the Event table down, which
allows for better overall performance for WebNative Venture.

Make a copy of the dblogd.conf file for safe keeping, and then edit the original dblogd.conf
file using your favorite text editor. Locate the Daemon State section, and insert a new line
right after the Running= flag. Add the text [Event Filter] (include the square brack-
ets). Add the StoreBackupEvents=1 line if you wish to store events for each backup in
the Events table. Add the UpdateBackupTable=1 flag if you wish to write file information
to the backupfile and backuppath tables with each FlashNet backup.

The resulting entry should look like this for a site that chooses to store backup events in the
Event table as well as store file information in the backupfile and backuppath tables:
[Event Filter]
StoreBackupEvents=1
UpdateBackupTable=1

Once the dblogd.conf file has been updated, you will need to restart the dblogd(1M) dae-
mon so that the changes take effect. Use the nativeadmin GUI > Database > Daemon >
Restart Daemon button to read in the new configuration information.

106
 Chapter 10

WebNative Venture data formats — the Data Fields tab

Clicking on the Data Fields tab presents the GUI shown in Figure 39. The GUI shows
information about the types of data stored in your database. It also allows you to open sub-
panels where you can add new fields or change the existing fields. Keep in mind that all
users will probably not need to see every field listed. You configure which of the fields users
see in another part of the GUI.
This link opens This link opens a This column describes Opens a subpanel Allows you to delete a
a subpanel subpanel where the type of data held where you can field from the database.
where you can you can change in each field. The type change the You can only delete
create new the attributes of constrains the infor- attributes of the fields you have created.
Data Fields. existing Data mation format and particular field.
Fields. how users enter data.

This pop-up list

allows you to limit the
data displayed in the
table.

This table lists the

categories of data that
have been defined in
your database. The
first column shows the
name of the fields as
they appear in
WebNative search
results (minus the
asterisks). Asterisks
indicate fields that
ship with WebNative
Venture. You cannot
delete these fields.
Fields you create will
not be marked in
this way.

These columns show whether special searching Indicates whether or not information is
mechanisms for a field have been turned on. stored as XMP data

FIGURE 39. The primary Data Fields GUI

Look through the fields listed in the primary Data Fields GUI and the information about
those fields. Some administrators will find everything they need in the fields that are already
there; others may want to add fields of their own. A pop-up list allows you to limit what
WebNative displays in the Data Fields subpanel. Sorting options include:
• All
Displays all Data Fields, including locked fields and custom, nativeadmin-defined fields

107
 Chapter 10: WebNative Venture data formats — the Data Fields tab

• Built-In
Built-in XMP fields that ship with WebNative Venture
• User
Displays only custom, user-defined fields
• Data Field Sets
As described in “Establishing Data Field Sets” on page 122, you can also customize
your own group of fields for display.

DATA FIELD NAMES. Information recorded in the database is kept in fields, and each of
these fields has a particular format, depending on the type of information stored in the field.
Some fields may require text, some numbers, and some, such as financial information, num-
bers in a particular format. The fields are distinguished from one another by different
names. Their names appear in the first column of the primary Data Fields GUI.

Some of the fields come from XMP specifications, such as you find in Photoshop files.
Xinet programmed WebNative Venture so that these fields appear automatically when you
install the database. These preprogrammed fields are marked by asterisks, and although
they can be hidden from users, they can’t be deleted from the system. Keep in mind that
Adobe has mapped all IPTC fields to XMP fields and in some cases used an XMP field
name that differs from the original IPTC name. Xinet, however, has maintained older IPTC
field names to ensure backwards compatibility. As a result, WebNative field names don’t
necessarily map to their newer Adobe XMP names. Table 4 on page 185 highlights where
Adobe has made changes to the names of fields.

When you add new fields for the database to record, you will give them names. You may
change these names and the field attributes any time you want. Although WebNative Ven-
ture will allow you to use any characters you want in your field names, keep in mind that
web browsers have to interpret what WebNative sends them, and that browsers are limited
to ISO Latin character sets. This means it’s not a good idea to use special characters in field
names. XMP also enforces naming conventions, which will be discussed in the following
subsections. For information about adding fields, see “Adding Data Fields” on page 109.
For information about changing names and attributes, see “Modifying or editing data
fields” on page 120.

DATA FIELD TYPES. The second column of the Data Fields table tells you each field’s type.
The type settings constrain the sort of information which can be entered in a field and help
to make sure users always enter information that will be useful for a search. Different types
also have ramifications for how much disk space the database uses for each entry. The five
possible field types include:
• Text
• Integer
• Floating Point
• Date
• Boolean

“Adding Data Fields” on page 109 provides more information about each of these.

108
 Adding Data Fields

DATA FIELD DESCRIPTIONS. The Data Field descriptions provide a bit more information
about the fields. Information is limited to 64 characters. You enter the information when
you create or edit a Data Field.

INDEXED AND FULLTEXT INDEXED KEYWORD TABLES. Both Indexed and FullText search-
ing produce faster keyword search results when used correctly. These features, however,
will also slow down system performance when data is being entered into the system, so
should be used carefully.

Having a data field Indexed will speed up searches when users are interested in finding a
target that begins with a given string. The database will keep an alphabetical reference table
of all the entries in a particular field to make searching conducted on that field faster. If a
particular field is not likely to be searched using a begins-with constraint, you don’t want to
turn on indexing.

Enabling a data field for FullText searching speeds up searches when users are interested in
finding a target that is a whole word of at least three characters. The database keeps a spe-
cial alphabetical index of discrete words in a FullText-enabled field to speed up searching
for complete words. The feature is not a good one to turn on if users are likely to search on
partial words, e.g., ation rather than station. The index allows users to search multiple
whole-word tokens.

For information about enabling Indexed and FullText searching, refer to “Enabling Indexed
and FullText searching of Keywords” on page 124.

XMP DATA FIELDS. The sixth column indicates whether or not data associated with a field
will be written as XMP into appropriate Adobe files. You’ll find more information about
XMP in the five subsections of “Adding Data Fields” beginning on page 109. “How Web-
Native reads data from files” on page 179 contains additional information. If you encounter
difficulties with XMP and WebNative Xinet TechNote 241 at www.xinet.com may offer
explanations.

Adding Data Fields The process for adding new fields varies according to the type of the field you add. The fol-
lowing subsections provide details.

Adding a text field

Text fields provide users with type-in boxes which accept ISO Latin characters, or pop-up
lists which consist of ISO Latin characters. While text fields take up more storage space
than other field types, they present the only way to store readable strings. If you are adding
a field which will hold only numeric data, you should use one of the numeric field types,
instead of a text field.

109
 Chapter 10: WebNative Venture data formats — the Data Fields tab

1. Click on the New Data Field link.

2. Select Text from the Field Type pop-up list. A subpanel which resembles Figure 2 will
appear

FIGURE 40. Adding a text Data Field

3. Type in a name for the field in the Name type-in box. You’re limited to a maximum of
64 characters. You may see a warning if you type in a name that violates XMP
standards (no spaces or “special characters” within the field name).

FIGURE 41. XMP standards for field names

4. Type in a description of the field in the Description type-in box. You’re limited, again,
to 64 characters.
5. Type in a value in the Max Length box. This value establishes the maximum number of
characters the text field can contain. The value you set here can not be edited later;
since, if you were to shorten the number of characters, entries to the database that were
made previously could be affected in unpredictable ways.
6. Type in a value in the Field Cols box. The value determines how many of the field’s
characters will show at one time in the user’s browser. If the number is smaller than the
Max Length value, text will disappear from view as the number of characters that the
user enters exceeds the Field Cols value. The user can shift the cursor position to see
any text temporarily hidden from view.
7. Type in a value in the Field Rows box. This value determines how many rows of text a
user gets for text. Each row will be the size set by the Field Cols value. If you set a

110
Adding Data Fields

Field Rows value greater than 1, text that exceeds the Field Cols value in the first row
will automatically spill over to the next row, etc.
8. When you are content with the settings, click the Add button.
9. [optional] You may, if you’d like, constrain users to selecting options by having the
options appear in a pop-up list. Clicking on the Add and Edit button will present a
subpanel similar to the one shown in Figure 42.

FIGURE 42. Constraining a text field to pop-up menu choices.

The top portion of the subpanel allows you to modify the attributes (except Max Length)
you’ve just established. You may change those values if you’d like. But, at this point
you’re probably more interested in the lower section of the subpanel, where you’ll
define what appears in your text pop-up list for the field (Step 11.).
10. [optional] Use the checkbox to Save into an XMP Packet. This option appears only
when the Data Field conforms to XMP naming standards (no spaces or “special
characters” within the name). If you enable this option, WebNative Venture will embed
any changes users make to this field as XMP metadata when users save the file, as long
as the file is being saved from an Adobe application (Acrobat, Illustrator, InDesign or
Photoshop) or any other application that uses Adobe-compliant XMP packets.
11. If you want to add pop-up entries, and none exist, click the Use Custom Pop-up Values
button so it is “on.” However, if the field has previously been used as a type-in text box
and you want to preserve those values, you may want to skip to Step 16. on page 112,
instead.
12. Type in an item for the pop-up list in the New Value field. You are constrained to Max
Length number of characters. Then click the Add button. That item will now appear in
the custom Pop-up Value List.
13. Continue adding entries to the pop-up list, clicking the Add button after each. You may
use the Delete or Delete all buttons if you notice mistakes in the Custom Pop-up Values
list.

111
 Chapter 10: WebNative Venture data formats — the Data Fields tab

14. [optional] If you happen to be editing a previously-established pop-up list, and want to
keep the older items in your new list, click on the Add Current Values button. The
lower pop-up list shows the previously-existing or current values.
15. When you have established the pop-up list you want, click the Save button. When you
do so, the Custom Pop-up Values will be stored as Current Values and will appear when
users interact with the field.
16. [optional] If you’re converting what was once a type-in field to a pop-up list and you
want to preserve the values that end users have previously entered in the field as
choices in the pop-up list, click on the Use Current Values button. (The Pop-up Values
list will show you what those values are.) You may want to use this feature in
conjunction with a Field Type option (set under the User Perms tab, as explained on
page 133) to help users enter metadata in a consistent manner.
17. Saving may be a two-part process. If you’ve done anything with pop-up lists, and
haven’t already clicked the Save button at the bottom of the GUI, be sure to do so. Then
click the Save button in the middle of the GUI to save any editorial changes to the data
field.

Adding an integer field

An integer is what we traditionally think of as a “counting number” or whole number. Inte-

gers can have negative value; but, you can’t express fractions or decimal values. Integers
are limited in size to values between -2147483648 and +2147483647. If you need to express
larger values or fractions, you should use a floating point field instead. See “Adding a Float-
ing Point field” on page 114 for more information.

To add an integer field:

1. Click on the New Data Field link.

2. Select Integer from the Field Type pop-up list. A subpanel which resembles Figure 43
will appear.

FIGURE 43. Adding an integer field

3. Type in a name for the field in the Name type-in box. You’re limited to a maximum of
64 characters. You may see a warning if you type in a name that violates XMP
standards (no spaces or “special characters” within the field name).

112
Adding Data Fields

4. Type in a description of the field in the Description type-in box. You’re limited, again,
to 64 characters.
5. Use the Integer Type pop-up list to constrain the integer to one of the following types:
• SMALLINT (2 bytes)
Integers of type SMALLINT only take 2 bytes of storage. You can represent values
between -32768 and +32767.
• TINYINT (1 byte)
Integers of type TINYINT take even less storage, i.e., 1 byte each. You can represent
values between -128 and +127.
• BIGINT (4 bytes)
Integers of the type BIGINT always consume 4 bytes of storage. The trade-off is that
you can store values between -2147483686 (2 gig) and +214748647.
6. Enter a value in the Field Size type-in box. This determines the size of the type-in box
end users see in their browsers. If you try to set a larger type-in box than required by
the Integer Type, WebNative users will only be able to type in the number of digits
allowed by the Integer Type.
7. If you are satisfied with the settings, click on the Add button. You may, however, want
to further customize the field. Go on to the next step if that’s true, without hitting the
Add button.
8. [optional] If you’d like to further constrain use of the field, click on the Add and Edit
button. The subpanel will update itself so that is resembles Figure 44.

FIGURE 44. Creating a pop-up list for an integer field

9. [optional] Use the checkbox to Save into an XMP Packet. This option appears only
when the Data Field conforms to XMP naming standards (no spaces or “special
characters” within the name). If you enable this option, WebNative Venture will embed
any changes users make to this field as XMP metadata when users save the file, as long
as the file is being saved from an Adobe application (Acrobat, Illustrator, InDesign or
Photoshop) or any other application that uses Adobe-compliant XMP packets.

113
 Chapter 10: WebNative Venture data formats — the Data Fields tab

10. If you want to add pop-up entries, and none exist, click the Use Custom Pop-up Values
button so it is “on.” However, if the field has previously been used as a type-in box and
you want to preserve those values, you may want to skip to Step 15. on page 114,
instead.
11. Type in an appropriate integer in the New Value field. Then click the Add button. That
integer will now appear in the custom Pop-up Value list.
12. Continue adding entries to the pop-up list, clicking the Add button after each. You may
use the Delete or Delete all buttons if you notice mistakes in the Custom Pop-up Values
list.
13. [optional] If you happen to be editing a previously-established pop-up list, and want to
keep the older items in your new list, click on the Add Current Values button. The
lower pop-up list shows the previously-existing or current values.
14. When you have established the pop-up list you want, click the Save button. When you
do so, the Custom Pop-up Values will be stored as Current Values and will appear when
users interact with the field.
15. [optional] If you’re converting what was once a type-in field to a pop-up list and you
want to preserve the values previously entered in the filed as choices in the pop-up list,
click on the Use Current Values button. (The Pop-up Values list will show you what
those values are.)
16. Saving may be a two-part process. If you’ve done anything with pop-up lists, and
haven’t already clicked the Save button at the bottom of the GUI, be sure to do so. Then
click the Save button in the middle of the GUI to save any editorial changes to the data
field.

Adding a Floating Point field

Floating point, because of its flexibility, is the most common way of representing real numbers
on computers. It stands in contrast to fixed point representation, where the degree of accuracy
is limited to a given number of digits. Basically, floating point allows you to express real
numbers that can be either very large, by virtue of the large number of digits before the dec-
imal point or very precise, by virtue of the large number of digits after the decimal point.
You can express values ranging from -1 x 10244 to -1 x 10-30, 0, 1 x 10-30 to 1 x 10244.

114
Adding Data Fields

To add a new floating point field:

1. Click on the New Data Field link.

2. Select Floating Point from the Field Type pop-up list. A subpanel which resembles
Figure 45 will appear.

FIGURE 45. Adding a floating point field

3. Type in a name for the field in the Name type-in box. You’re limited to a maximum of
64 characters.You may see a warning if you type in a name that violates XMP
standards (no spaces or “special characters” within the field name).
4. Type in a description of the field in the Description type-in box. You’re limited, again,
to 64 characters.
5. Select Floating Point in the Field Type pop-up list.
6. Establish the format in which users can enter values (and view them) in their browsers.
To do so, use the two Max Digits type-in boxes. The value you type into the Total box
sets the number of digits used to express the field you’re defining, including the
number of digits on both sides of the decimal point plus 2 more mandatory digits (one
for the decimal point itself and the other to allow for the possibility of a negative sign).
The value you type into the Decimals box sets the number of digits to the right of the
decimal. For FLOAT fields, the Total should be an integer between 1 and 244. The
Decimals value may be from 0 to 30; but, should not exceed two less than the Total
value.
When establishing these values, keep in mind that entries for each float will be stored
as strings with each digit requiring 1 byte of storage plus the additional two bytes
mentioned above. For example, if you establish a field requiring 5 + 2 digits (i.e., five
places before the decimal and two after), each entry will require 9 bytes of storage. If
you have a growing number of entries in the database with float fields requiring large
amounts of storage, you could eventually consume significant amounts of memory.
You do not, therefore, want to make these fields any larger than necessary.
7. Enter a value in the Field Size type-in box. This determines the size of the type-in box
which appears in users’ browsers. If you try to set a larger type-in box than required by
the Float Type, WebNative users will be only be able to type in the number of digits
allowed by the Float Type. If you set a smaller Field Size box than the number a user
enters, he or she will be able to scroll to see the ends of the number in the browser; but,
will not be able to see the entire number at once.

115
 Chapter 10: WebNative Venture data formats — the Data Fields tab

8. If you are satisfied with the settings, click on the Add button. You may, however, want
to further customize the field with pop-up selections. If that’s true, go on to the next
step without clicking the Add button.
9. [optional] If you’d like to further constrain use of the field, click on the Add and Edit
button. The subpanel will update itself so that is resembles Figure 46.

FIGURE 46. Creating a pop-up list for a floating point field

10. [optional] Use the checkbox to Save into an XMP Packet. This option appears only
when the Data Field conforms to XMP naming standards (no spaces or “special
characters” within the name). If you enable this option, WebNative Venture will embed
any changes users make to this field as XMP metadata when users save the file, as long
as the file is being saved from an Adobe application (Acrobat, Illustrator, InDesign or
Photoshop) or any other application that uses Adobe-compliant XMP packets.
11. If you want to add pop-up entries, and none exist, click the Use Custom Pop-up Values
button so it is “on.” However, if the field has previously been used as a type-in box and
you want to preserve those values, you may want to skip to Step 16. on page 117,
instead.
12. Type in an appropriate floating point value for the pop-up list in the New Value field.
Then click the Add button. That value will now appear in the custom Pop-up Value list.
13. Continue adding entries to the pop-up list, clicking the Add button after each. You may
use the Delete or Delete all buttons if you notice mistakes in the Custom Pop-up Values
list.
14. [optional] If you happen to be editing a previously-established pop-up list, and want to
keep the older items in your new list, click on the Add Current Values button. The
lower pop-up list shows the previously-existing or current values.
15. When you have established the pop-up list you want, click the Save button. When you
do so, the Custom Pop-up Values will be stored as Current Values and will appear when
users interact with the field.

116
Adding Data Fields

16. [optional] If you’re converting what was once a type-in field to a pop-up list and you
want to preserve the values previously entered in the filed as choices in the pop-up list,
click on the Use Current Values button. (The Pop-up Values list will show you what
those values are.)
17. Saving may be a two-part process. If you’ve done anything with pop-up lists, and
haven’t already clicked the Save button at the bottom of the GUI, be sure to do so. Then
click the Save button in the middle of the GUI to save any editorial changes to the data
field.

Adding a Date field

Date fields establish the calendar date and optionally, the time of an event. WebNative Ven-
ture Date fields also provide a short-cut Today button to supply the current date. To create a
Date field:

1. Click on the New Data Field link.

2. Select Date from the Field Type pop-up list. A subpanel which resembles Figure 47
will appear.

FIGURE 47. Adding a date field

3. Fill in the Name and Description type-in boxes. You will be limited to 64 characters in
each. You may see a warning if you type in a name that violates XMP standards (no
spaces or “special characters” within the field name).
4. Select the field’s Display Type. You may choose between displaying dates that
resemble any of the following:
January 31, 2020
Jan 31, 2020
1/31/2020
1/31/2020 14:34:56 (24-hour clock)

117
 Chapter 10: WebNative Venture data formats — the Data Fields tab

1/31/2020 2:34:56 pm (12-hour clock)

Friday, 1/31/2020 12:34:56 PM
31 January, 2020
31 Jan, 2020
31/1/20
31/1/2020
31/1/2020 14:34:56 (24-hour clock)
31/1/2020 12:34:56 PM (12-hour clock)
FRIDAY, 31/1/2020 2:34:56 PM
20/1/31
2020/1/31
2020/1/31 2:34:56 PM
5. Click on the Add button once you’re satisfied with the settings for the field, or if you
want to supply a pop-up list of dates, go on to the next step without clicking the Add
button.
6. [optional] If you want to establish a date pop-up list, click on the Add and Edit button.
A window similar to the one shown in Figure 48 will appear. The actual interface,
however, will depend on the Display Format for the date field.

FIGURE 48. Establishing a pop-up date list

7. If you want to add pop-up entries, and none exist, click the Use Custom Pop-up Values
button so it is “on.” However, if the field has previously been used as a type-in box and
you want to preserve those values, you may want to skip to Step 13. on page 119,
instead.
8. Click the Use Custom Pop-up Values button so it is “on.”
9. The New Values row contains pop-up lists for each element in the Display Format.
They are arranged in the same order as in the Display Format. Set each of these to
create the date you want to add in the new pop-up list you’re creating. When you are
done, click the Add button.

118
Adding Data Fields

10. Continue adding entries for the new pop-up list, clicking the Add button when you have
finished an entry. You may use the Delete or Delete all buttons if you notice mistakes in
the Custom Pop-up Values list.
11. [optional] If you happen to be editing a previously-established pop-up list, and want to
keep the older items in your new list, click on the Add Current Values button. The
lower pop-up list shows the previously-existing or current values.
12. When you have established the pop-up list you want, click the Save button. When you
do so, the Custom Pop-up Values will be stored as Current Values and will appear when
users interact with the field.
13. [optional] If you’re converting what was once a type-in field to a pop-up list and you
want to preserve the values previously entered in the filed as choices in the pop-up list,
click on the Use Current Values button. (The Pop-up Values list will show you what
those values are.)
14. [optional] Use the checkbox to Save into an XMP Packet. This option appears only
when the Data Field conforms to XMP naming standards (no spaces or “special
characters” within the name). If you enable this option, WebNative Venture will embed
any changes users make to this field as XMP metadata when users save the file, as long
as the file is being saved from an Adobe application (Acrobat, Illustrator, InDesign or
Photoshop) or any other application that uses Adobe-compliant XMP packets.
15. Saving may be a two-part process. If you’ve done anything with pop-up lists, and
haven’t already clicked the Save button at the bottom of the GUI, be sure to do so. Then
click the Save button in the middle of the GUI to save any editorial changes to the data
field.

Advanced administration option: additional date formats

You can customize date formats if the default values don’t suit your needs. Check the Xinet
Technote 134 available at www.xinet.com for details.

119
 Chapter 10: WebNative Venture data formats — the Data Fields tab

Adding a boolean field

A boolean field is one that can have one of two possible values, for example, true/false. To
add a boolean field:

1. Click on the New Data Field link.

2. Select Boolean from the Field Type pop-up list. A subpanel which resembles Figure 49
will appear.

FIGURE 49. Adding a boolean field

3. Fill in the Name and Description type-in boxes. You will be limited to 64 characters in
each. You may see a warning if you type in a name that violates XMP standards (no
spaces or “special characters” within the field name).
4. Select the field’s Display Type. You may choose between:
Check Box
True/False
Yes/No
5. Click on the Add button to create the field.
6. [optional] If you would like to save the information in this field as an XMP packet,
refer to “Modifying or editing data fields” on page 120.

Advanced administration option: additional boolean pairs

You can customize boolean pairs if the default values don’t suit your needs. Check the Xinet
Technote 134 available at www.xinet.com for details.

Modifying or editing You may modify existing Data Fields. When you do so, you won’t change existing data
Data Fields stored in the fields. What you are actually changing is the way the data is displayed for
users, not the data itself.

120
 Deleting Data Fields

To modify an existing data field:

1. There are several ways to begin the process. Click the pencil icon in the Data Field
subpanel for the field you want to modify, or click the Edit Data Fields link, or the Add
and Edit button. Figure 50 shows what you would see if you were editing a boolean field.

FIGURE 50. Editing a boolean Data Field

2. If you are not viewing information about the existing field you’re interested in, select
the correct field from the pop-up Name list.
3. At this point, you may change the field’s name and description. You may also be able to
change details about how it displays information or how users interact with it. The
details depend on whether the field is one of WebNative Venture’s standard fields as
well as the type of field you’re modifying. “Adding Data Fields” on page 109 gives
details about changing attributes of each type.
4. When you are satisfied with the settings, click the Save button.
5. If the field uses a pop-up list, you may also edit those entries. The field type determines
the interaction.Turn to Step 9. on page 111 for details about text pop-up lists. Turn to Step
10. on page 114 for details about integer pop-up lists. Turn to Step 11. on page 116 for
details about floating point pop-up lists. Turn to Step 6. on page 118 for information
about date pop-up lists.
6. [optional] Use the checkbox to Save into an XMP Packet. This option appears only
when the Data Field conforms to XMP naming standards (no spaces or “special
characters” within the name). If you enable this option, WebNative Venture will embed
any changes users make to this field as XMP metadata when users save the file, as long
as the file is being saved from an Adobe application (Acrobat, Illustrator, InDesign or
Photoshop) or any other application that uses Adobe-compliant XMP packets.
7. You may modify another field by selecting it from the pop-up Name list, or return to
other activities.

Deleting Data Fields There are a number of places in the Data Fields GUI where you can delete data fields that
have been created on your system. You can’t delete those that ship with WebNative Venture.
You can delete fields in the primary Data Fields GUI, from the Modify, and Add and Edit GUIs.

121
 Chapter 10: WebNative Venture data formats — the Data Fields tab

Be careful when you do this, because when you delete a data field, all previously-stored
data within that field also disappears.

Establishing Data Field The Add Data Field Set tab, shown in Figure 51, allows you to more conveniently group
Sets Data Fields into groups or sets. Using these sets will save time when you're building Tem-
plates or simply reviewing Data Fields. In the latter case, rather than viewing all the Data
Fields on your system, you can look at those fields in particular sets.

FIGURE 51. Adding a Data Field Set

WebNative Venture ships with two Data Field Sets already established:
• Built-In
Built-In Data Fields include standard XMP fields automatically read in by WebNative
Venture. These fields start out locked—and, WebNative Venture users are unable to
change their values. However, at nativeadmin’s discretion, XMP fields can become
editable.]
• User
User-defined Data Fields include any XMP fields added by the WebNative Venture
administrator.

You may also define your own Data Field Sets using the Add Data Field Set interface.

122
Establishing Data Field Sets

Adding a Data Field Set

To add a Data Field Set:

1. Click on the Add Data Field Set subtab. You’ll see an interface that resembles
Figure 51.
2. Provide a name for the set and, optionally, a description of it.
3. Using the Data Fields table in the lower portion of the browser window, click those
items you would like to include in the set you are defining.
4. When you are satisfied with the collection, click the Save button at the bottom of the
table. Your newly-defined set will now be available to use when building Templates or
reviewing Data Fields.

Editing a Data Field Set

If the WebNative Venture administrator has already defined Data Field Sets on the system,
they may be edited at any time. Please note that it is not possible to edit either of the two sets
that ship with the system, i.e., the Locked or User Data Field Set.

To edit a set:

1. Click on the Edit Data Field Set subtab. You’ll see something resembling Figure 52.

FIGURE 52. Editing a Data Field Set

2. Select the set you would like to edit from the Data Field Set pop-up menu.

123
 Chapter 10: WebNative Venture data formats — the Data Fields tab

3. Click and unclick any Data Fields you would like to add or remove from the set.
You may also edit the Description or delete the Data Field Set entirely by clicking the
Delete button next to its name.

Enabling Indexed and For an overview of Indexed and FullText searching, please refer to “Indexed and FullText
FullText searching of indexed keyword tables” on page 109.
Keywords
Enabling a regular index on a keyword field improves search speeds for that field. Searches
on a field with a regular index can be performed by selecting the Begins With search option
and entering any number of characters.

Enabling a FullText index on a keyword field both increases speed and introduces the abil-
ity to perform token searches. A token is any word delimited by spaces. Therefore a search
for fish will return matches for fish but not fishing. Searches on an field with a FullText
index can be performed by selecting the Contains the Word search option and entering a
word of three letters or more. (Searches performed on words with fewer than three letters
will simply fail. Those searches should be done using the Contains search option, instead.)

It is important to note that caution must be used when choosing fields on which you will
enable an index. While regular indexes can be added to any field, FullText indexes can only
be added to text fields. As keywords are applied to files in the Venture database, each index
that you have added will grow. If there are a number of indexes, or if there are a great num-
ber of files with keywords, the index can become so large that any new data inserted into
the table will be inserted at a slower speed. This can have the overall affect of decreasing
database performance; indexes should therefore be added with caution, and in limited num-
bers.

Procedure for enabling a regular index

1. Do a full backup of the database using the WebNative nativeadmin GUI’s Database >
Backup tab, as described in “Backing up and restoring data” on page 97.
2. Inside the WebNative nativeadmin GUI’s Data Fields tab > Edit Data Fields page,
locate the data field that you wish to index. Click on the edit icon next to the field, and
note the numeric value for lang.keywordid that appears in the ensuing window. Also,
make note of the value for the Max Length variable. For example, if you have a 32-
character text field, you should note the value lang.keywordid61 which indicates the
keyword ID for that field is 61, and that the Max Length value is 32.
3. Stop dblogd by clicking the Stop Daemon button in the nativeadmin GUI’s Database
tab > Daemon page. This will prevent events from being added to the database while
you are updating your keyword1 table.
4. Login to the MySQL client console. Using the keyword ID and Max Length values
obtained in Step 1., run the following query to add the index to the field:
alter table keyword1 add index BY_FIELDXXX (FieldXXX(nn));
where FieldXXX is the keyword ID as it exists in the keyword1 table, and nn is the Max
Length of the field as configured in the nativeadmin GUI at the time the field was
created. Using the example value in Step 1., the query would look like this:
alter table keyword1 add index BY_FIELD61 (Field61(32));

124
Enabling Indexed and FullText searching of Keywords

5. When done, verify the field are indexed by typing:

show index from keyword1;
6. When you are satisfied with the results, you may choose to logout of the MySQL client.
The nativeadmin GUI’s Data Fields tab > Data Fields page should now show a check
mark in the Indexed column for that data field.
7. Restart dblogd by clicking the Start Daemon button in the nativeadmin GUI’s
Database > Daemon page so that event processing may resume.

Should you encounter any problems, please contact Xinet Technical Support
(help@xinet.com).

Procedure for enabling a FullText index

Only start this process when there is low system activity, since FullText index creation can
be CPU-intensive depending on the size of the table and the number of affected entries.

1. Do a full backup of the database using either the WebNative nativeadmin GUI
Database > Backup tab.
2. Inside the WebNative nativeadmin GUI’s Data Fields tab > Edit Data Fields page,
locate the data field that you wish users to be able to search using tokens. Click on the
edit icon next to the field, and from the ensuing screen note the numeric value for
lang.keywordid. Also, make note of the value for the Max Length variable. For
example, if you have a 32-character text field, you should note the value
lang.keywordid61 which indicates the keyword ID for that field is 61, and that the Max
Length value is 32.
3. Stop dblogd by clicking the Stop Daemon button in the nativeadmin GUI’s Database
tab > Daemon page. This will prevent events from being added to the database while
you are updating your keyword1 table.
4. Login to the MySQL client console. Using the keyword ID and max length values
obtained in Step 1., run the following query to add the index to the field:
alter table keyword1 add fulltext FT_FIELDXXX (FieldXXX(nn));
where FieldXXX is the keyword ID as it exists in the keyword1 table, and nn is the Max
Length of the field as configured in the nativeadmin GUI at the time the field was
created. Using the example value in Step 1., the query would look like this:
alter table keyword1 add fulltext FT_FIELD61 (Field61(32));
5. When done, verify the field are indexed by typing:
show index from keyword1;
6. When you are satisfied with the results, you may choose to logout of the MySQL client.
The nativeadmin GUI’s Data Fields tab > Data Fields page should now show a check
mark in the FullText column for that data field. Additionally, the Contains the Word
search option should now appear as a possible search option in House search style. (If
you have a customized version of the House search style that was created prior to
installing WebNative Venture, you should update its searchquery.js file to include the
changes Xinet made to allow this kind of search on keyword fields.)
7. Restart dblogd by clicking the Start Daemon button in the nativeadmin GUI’s Database
> Daemon page so that event processing may resume.

125
 Chapter 10: WebNative Venture data formats — the Data Fields tab

Should you encounter any problems, please contact Xinet Technical Support
(help@xinet.com).

126
 Viewing existing templates

Chapter 11

WebNative Venture templates — the Templates tab

Although WebNative Venture can store an unlimited number of data fields, most users or
groups of users would find it distracting to see all of the fields that exist. Some fields may
also be of a sensitive nature, and, therefore, not appropriate for every user to see. Templates
let you preset data fields in groups so you can assign each user to a particular template that
contains a particular subset of data fields for them to view and search through.

WebNative Venture provides two ways for you to screen which fields users see. This chap-
ter describes setting up templates in which you establish groups of fields and the order of
their appearance when viewed from browsers. Chapter 12 describes how to further refine
which fields individual users or groups of users see within their template

Viewing existing Clicking on the Templates tab opens the GUI shown in Figure 53. The GUI allows you to
templates find out information about existing templates and delete those templates that are no longer
useful. The GUI also allows you to open subpanels where you can edit templates and add
new templates.

This pop-up
list shows
existing
templates.
The selection
you make
determines
what you’ll
see below.

This shows
the data
fields used by
the template
you’ve
selected and
the order in
which the
fields appear
in browsers.
You may have
to use the
scroll bar to
see all the
fields.

FIGURE 53. The primary Templates GUI

To find out more information about any existing template:

127
 Chapter 11: WebNative Venture templates — the Templates tab

1. Click on the Templates tab or Templates link to open the primary Templates GUI.
2. Select the template by name in the Templates pop-up list. The data fields contained in
the template will be listed in the lower portion of the GUI. You may edit the template if
you wish, by clicking on the Edit Template button. You may also delete some, but not
all, templates by clicking on the Delete Template button.

Templates shipped with WebNative Venture

WebNative Venture ships with two templates:

• Classic
The Classic template allows you to preserve the classic WebNative interface for users,
yet still use the database to record information within the WebNative and FullPress file
system. This template is completely empty of metadata search fields, so all metadata
capabilities can be hidden from users. If you select the classic WebNative Venture tem-
plate, your users’ search experience will be exactly the same as it was with WebNative.
If you wish to present users with WebNative Venture metadata fields, use the second
built-in WebNative Venture template, or design your own. You may also use the classic
template as a starting point for very simple templates, although you can do the same
thing by using the New Templates button.
• NAA/IPTC
The NAA/IPTC template contains the data fields that have been established by the NAA/
IPTC standards (which are now subsumed within XMP standards). It is a good starting
point for creating other templates, so many template builders will want to begin by
copying its fields into a new template. While you can’t remove fields from the template,
you can add fields to it, as well as change the order of appearance of any of its fields.

Adding templates To add a new template:

1. Click the New Template link. A subpanel resembling the one shown in Figure 54 will
appear.

FIGURE 54. Naming a new template

2. Fill in a name and description for the template, and then, if you’d like, use the Copy
Template pop-up list to copy an already-existing template to use as the basis for your
new template.

128
 Adding templates

3. Click on the Create and Edit Template button. The GUI will refresh, presenting a
subpanel resembling Figure 55, although the exact appearance depends on whether you
have chosen to copy an existing template. (Figure 55 uses the NAA/IPTC template as
its basis.)

The name of the new tem-

plate and its description
appear here. You may
change them if you’d like.

Use this list and the Add

button to add existing data
fields to the new template.

Use the up and down

buttons to establish the
order in which fields will
appear in the template.

You can change fields you’ve created as pop-up lists to type-in boxes. You can
also force them to remain as pop-up lists. Locking a field makes it “read only.”
(Built-in fields will be locked so you can’t change the way users interact with
them. You may, however, delete them from the new template.)

FIGURE 55. Establishing the fields a new template uses

4. Use the Add Data Field pop-up list to add fields to the template. The pop-up list shows
all the fields in your system that aren’t already listed in your template. For information
about creating new fields, refer to “Adding Data Fields” on page 109.
5. Use the arrow buttons to change the order in which fields will appear in WebNative.
The “up” arrow will move the field up one level; the “down” arrow will move the field
down one level.
6. If you have based the template on an existing one, you may want to delete fields that
aren’t pertinent. Use the Delete button to remove a field. Deleting a field doesn’t
remove it from the database; it simply removes the field from the template you are
currently building.
7. If you want to keep fields as “read only,” i.e., allow users to see their contents but not
change them, click on the Locked button. You’ll notice that all predefined WebNative
Venture fields are permanently locked. You can’t open them up to user-editing. You
may, however, delete them from the template you’re defining.
8. Decide whether you want to preserve the pop-up lists that have been previously defined
for given data fields or offer type-in boxes in the template you’re defining. This option
only exists for fields that already have pop-up lists defined. If you’d like to preserve a
pop-up list, make sure the Pop-up button for the field is selected. If you’d prefer a type-
in box, click on the Edit button. If you choose to override the pop-up list, the type-in

129
 Chapter 11: WebNative Venture templates — the Templates tab

box will use the constraints for presenting information established when the field was
created or last edited. While this may seem round-about in this context, the option
exists to provide greater flexibility when you are establishing template variants, as
described in “Adding permission sets” on page 131.
9. When you are satisfied with your settings, click the Save button. If you click the Cancel
button before the Save button has been clicked, the template editing dialog will
disappear. The template will still exist, but any changes you may have made will
disappear.

Editing templates You may edit any template. To do so from the Templates subpanel:

1. Select the template you want to edit from the Templates pop-up list. The list contains
every template on your system. Please note, that if you select one of the predefined
WebNative Venture templates, you cannot change any of the fields shipped with the
product. If you have added new fields, you can edit those fields.
2. Click on the Edit Template button. A GUI similar to the one shown in Figure 55 on
page 129 appears, although actual contents will depend on the template you select.
3. The options are exactly like those presented in setting up templates, beginning with
Step 4. on page 129. Follow the directions there if you need more help.

Deleting templates You can delete templates that you are no longer using. When you do so, you won’t delete
any stored data; just the particular way of showing data that is determined by that template.
To delete a template:

1. In the Templates subpanel, select the template name from the Templates pop-up list.
This list contains every template on your system.
2. Click on the Delete Template button. Please note that you cannot delete templates that
ship with WebNative Venture. You can delete only those that have been created after
installation.
3. Confirm that you actually want to delete the named template. The template will be
removed.

130
 Adding permission sets

Chapter 12

Assigning templates to and customizing them for

individual users — the UserPerms tab

After you have established templates, you will need to assign them to users. Before you do
that, however, you might want to further customize the way users see and interact with the
information to which the templates provide access. For example, if you were to create a
template for “Ad Agencies,” you might then establish a subset for “Production” and one for
“Direction,” where directors would have permission to change special “Project Approval”
fields. Xinet refers to these subsets as permission sets. You set them up through the User
Perms portion of the GUI.

Clicking on the User Perms tab will open the User Perms GUI shown in Figure 56. This
interface, along with its subpanels, allows you to refine individual user interactions with
templates through permission sets.
Opens a subpanel
where you can hide or
Opens a subpanel change the interaction
where you can create for any field in the
subsets of a template. subset.

These pop-up lists

allow you to assign
subsets of any
template to individual
users.

Confirms assignment

FIGURE 56. The primary User Perms GUI

Adding permission sets You create permission sets by granting permission for users to see and interact with each
field within the parent template. You don’t have to define permission sets should a single
template satisfy all your users; but, in many cases you will want to streamline templates for
different kinds of use.

131
 Chapter 12: Assigning templates to and customizing them for individual users — the UserPerms tab

To establish a new permission set:

1. Click on the Add Permission Set link. A subpanel similar to Figure 57 will appear. The
actual contents, however, will depend on the selected template when it opens.

FIGURE 57. Adding a new permission set

2. Select a template from the For Template pop-up list.

3. Type-in a name for the variant in the Permission Set type-in box. You are limited to 64
characters.
4. [optional] If you or another administrator has previously established permission sets for
the selected template, you may use those settings as a starting point for your new set by
selecting the set from the Copy Permset pop-up list.
5. Set permission attributes for each field in the template. (SaveXMP status is presented in
the first column in case you want to consider whether or not the data field is going to be
saved as XMP before you decide what permission you assign.) There are options for
Settings which take precedence over those for Field Type. The attributes include:
Settings
• Visible
This setting determines whether or not the information in the field will be visible to
users when they open Info windows for files.
• Search
This setting determines whether or not the field appears as a “search-on” option when
the user is searching through entries.
• Browse
This setting determines whether or not the field appears in “long view” when a user is
browsing through files. (If you make a Data Field browseable, it will automatically
become visible.)

132
Adding permission sets

• Uploader and Required in Uploader

Clicking Required in Uploader automatically checks both fields. You can, however
select Uploader alone. These settings prescribe whether information about a file might
be requested or required when using the Xinet Uploader desktop utility to copy files to a
WebNative server. Figure 58 provides an example of an Uploader requiring metadata.

Example of required
information for
uploading

FIGURE 58. Some Uploaders require users to fill in metadata

“Uploader Manager” on page 23 introduces the Uploader utility. “Uploader: behind the
scenes” on page 135 provides details about log and configuration files that might
interest some administrators.
Field Type
• Edit
This setting determines whether type-in boxes will override established pop-up lists.
Selecting Edit will establish a type-in box for the template variant you are building.
Whether or not you have this option depends on the settings you established for the
template. For the Edit option to be available now, you must have first established a pop-
up list when you set up the field, and also set the Edit option to override the pop-up list
when you set-up the template. (For details, refer to the information about the Use
Custom Pop-up Values option in “Adding Data Fields” on page 109, and to information
about Edit vs. Pop-up in “Adding templates” on page 128.)
• Pop-up
This establishes that the field will remain a pop-up list in the variant you are building.
The option only appears in fields for which you established pop-up values when you or
another administrator set up the field.
It is possible to select both Pop-up and Edit for a given field. When you do, in
conjunction with establishing that the Data Field also Use Current Values (explained on
page 112), you create a special kind of Pop-up field with a type-in box next to it. This is
a useful feature when you want to allow users to change values with some freedom, but
also want a way to help them avoid entering information that, although, different from
another entry, is meant to be the same thing; e.g., using xinet vs. Xinet. (Such small
differences might make a huge difference with WebNative search operations or for
Triggers and Actions.) The pop-up list beside the editable field allows a user to first

133
 Chapter 12: Assigning templates to and customizing them for individual users — the UserPerms tab

check if another similar value for that field exists. Rather than entering xinet, your user
could find Xinet in the list and set the field’s value in that way.
To keep the pop-up list from becoming too long over time, it has been engineered to
only show values in current use; not historic. The box allows any user with appropriate
user permissions to type in a new value. Once saved that value will appear as a Pop-up
value for that Data Field in other files that share the same Userperms. Only values that
are currently assigned to files appear in the list. If a pop-up label is only applied to one
file and someone changes and saves the value for that field in the file, the value will
disappear altogether from the Pop-up list.
It is also possible to select both Pop-up and Edit for a field in conjunction with
establishing that the Data Field will use Custom Values (described on page 111). In this
case, the behavior would be similar to above except the Custom Values will always
remain in the pop-up list, with only user-added values changing according to use.
• Built-In
Built-In fields can be viewed but not changed. This setting overrides Pop-up and Edit
settings.
6. When you are satisfied with all the settings, click the Add button. You will then have
completed adding a permission set for the template.

Editing or deleting You may want to edit or delete previously established permission sets. To do so:
permission sets
1. Click on the Edit Permission Sets link. A subpanel similar to Figure 59 will appear:

Use the pop-

up list to
establish the
permission
set you want
to change or
delete.

FIGURE 59. Editing an existing permission set

2. Use the For Template pop-up list to establish the template whose permission set you
want to revise.
3. Use the Permission Set pop-up list to establish the particular set. All previously-
established sets for the selected template will appear in the list.

134
 Assigning templates and permission sets to users

4. If you’re not already familiar with working with the settings in the table at the bottom
of the subpanel, refer to Step 5. on page 132. Reset Settings and Field Type attributes as
desired.
5. When you are happy with the new settings, click the Submit button. Or if you want to
delete the particular permission set, click the Delete button. This will not affect the
parent template in any way.

Assigning templates and Once you’ve set up permission sets for templates, you’re ready to assign them to users or
permission sets to users groups of users. Through permission sets, you can customize which fields users see and
how they interact with them.

To assign a template and permission set to a user:

1. Click on the User Perms link. You should see something that resembles Figure 56 on
page 131.
2. Select from the User pop-up list the user whose database interactions you want to
configure.
3. Select a template from the User Template pop-up list
4. Select a permission set from the Current Set pop-up list.
5. Click on the Submit button.
6. [optional] If this is the first time you have assigned a new permission set, you might want
to open another browser and try it as a user, to make sure it gives your user the
experience you want.

Uploader: behind the The Uploader and Uploader Manager generate log and configuration files that might inter-
scenes est some administrators. A summary follows.

Uploader Manager
• Manager.log contains a log of all clients generated by the Uploader Manager.
Home:
Mac OS X/Users/username/Library/Logs/
Log entries have the following format:
[timestamp] Created ConfigName: SummaryURL -> OutputPath
The log will also contain any fatal error messages generated by the application. Errors
will have the format:
[timestamp] ERROR ErrorMessage
• Manager.prefs contains preferences for the Uploader Manager. This includes applica-
tion-specific settings as well as a list of all Uploader configurations. While the format is
in plain English and fairly easy to read, this file should not be modified by hand.
Home:
Mac OS X /Users/username/Preferences/

135
 Chapter 12: Assigning templates to and customizing them for individual users — the UserPerms tab

Uploader
• Uploader.log contains a log of every file and folder transmitted by the Uploader.
Home:
Mac OS X/Users/username/Library/Logs/
The log format is as follows:
[timestamp] LocalIPAddress FilePath RemoteFileName
FileSize HexEncodedTransferFlags
The transfer flags describe significant events that happened during the transfer. More
than one can apply, and when that happens, they will be added together, with all results
represented in hex. The flags include:
20 – File uploaded
21 – Directory created
22 – File uploaded was renamed by user
23 – File uploaded overwrote a file on the server
24 – There was a catastrophic error during transfer
The log will also contain any fatal error messages generated by the application. They
have the format:
[timestamp] ERROR ErrorMessage
• Configuration contains all the information the Uploader needs to behave as configured
in the Uploader Manager. Again, while written in plain text, it shouldn't be modified by
hand.
Home:
Mac OS XApplication Bundle/Contents/Resources/
• KeywordCache
In order to reduce network traffic and login time, the Uploader will cache a Webnative
user’s keyword template for up to a week. That information is stored in this file.
Home:
Mac OS XApplication Bundle/Contents/Resources/

136
 Definitions

Chapter 13

Actions and Trigger Sets quick-start guide

This quick start guide walks you through configuring your first WebNative Venture Trigger
Set. The particular Trigger Set we build in this chapter will instruct the database to copy a
file to a folder of your choosing and also send email to you whenever a user marks a field
called test approval with Yes.

Definitions • ActionAn executable that is run by the WebNative Venture

database trigger
• Action SettingA set of variables that affect how an Action runs
• Trigger RuleEstablishes when to run an Action or series of Actions.
Trigger Rules are comprised of the Data Field with which the rule is associated, the
Action to run (with all its Settings), and what to do if the Action fails.
• Trigger SetA group of Trigger Rules and the Active Paths for those
Trigger Rules
• Active PathFile system locations that are applicable for a specific
Trigger Set. If conditions in a Trigger Rule are met for a file or directory within these
paths, then the Actions for that Trigger Rule will run.
• On FailureHow to proceed in case the Action fails. If set to Continue the next Action in
the series (if any) will run. Exit will cause a silent exit. Exit and Notify will send email
using the On Failure email Settings for the Trigger Set.

Creating your first Creating an Action

WebNative Venture
Trigger Set To set up an Action:

1. Following the instructions in “Adding a boolean field” on page 120 of the WebNative
Administration Guide, create a boolean data field called test_approval with display
type Yes/No.
2. Add the data field to a template and configure your test user to have edit access to this
field in his or her assigned PermSet.
3. Verify that the database daemon is running on the server in the Daemon window of the
Database tab.

137
 Chapter 13: Actions and Trigger Sets quick-start guide

4. Click on Actions in the WebNative Administration window. As shown in Figure 60,

you will see a list of all of the Actions that are included with WebNative Venture 6.0.
None of the Actions in Figure 60 have Settings yet.

FIGURE 60. The Actions window

5. Click on copy to add a new setting to the copy Action.

6. In the New Setting window, name the new setting copy to my folder. Then, enter a
description.
7. Add a destination path into which files and folders will be copied.
8. You must choose an option from the Overwrite/Append/Fail drop-down menu. This
option will determine whether existing files and folders in the destination will be
overwritten, copied with a unique number appended, or whether the copy will simply
fail if an item with the same name already exists in that path.
For this example, please select the third option, Fail, from the drop-down list.
9. Click the Save button.
10. Because we also will be configuring an email Action, it is important to verify that your
server is able to send email. Test this using the command-line mail application included
with your operating system before continuing. If you need to know more about this
application on UNIX platforms see the man page on mail(1) or Mail(1).
11. Click on email to add a new Setting to the email Action.
12. In the New Setting window, first name your Setting Notify Me. Then,
enter a description.
13. Enter your email address (or the address to which mail will be sent) in
the To field.
14. [optional] You may add variable in the Subject and Body fields that refer to the file,
which when updated, initiates the Action. Set your Subject field to read Notify Me
about ${XFILESHORT}!. Be careful about capitalization.
Also, to the Body field, add something like:
Hey!

138
Creating your first WebNative Venture Trigger Set

The keyword ${XKEY} for file ${XFILESHORT} was changed by

${XUSER}. You should check it out here:
http://your.server.com/webnative/imageinfo?${URLPATHNAME}
Sincerely,
Your WNV Trigger Set
Substituting the name of your server in place of your.server.com.
15. Save your Setting.
16. Now, add another Setting to the email Action called Notify Me Fail, again using your
email address in the To field. The Subject field for this Action should read:
Your Trigger Set Failed!
The Body field for this Setting should read:
Thought you'd want to know that your Trigger Set failed. It was
trying to perform Actions on "${XFILE}".
Sincerely,
Your WNV Trigger Set
17. Save your Setting.
18. You can now see three Settings and their descriptions in the list of Actions: one for the
copy Action and two for email.

FIGURE 61. Checking Trigger Sets

Note:
• To delete a Setting, click the trash can icon next to that Setting.
• To jump directly to a Setting and edit it, click the pencil next to that Setting.

139
 Chapter 13: Actions and Trigger Sets quick-start guide

Creating a Rule

Now, it’s time to create an Trigger Set that uses the Action Settings you just created:

1. Click on Trigger Sets to see a list of all of the current Trigger Sets on the system. If this
is your first Trigger Set, this window will show No Trigger Sets Defined, as
Figure 62 shows.

FIGURE 62. Reviewing current Trigger Sets

As you add more Trigger Sets, this window will prove useful for reviewing the what’s
on your system.
2. Create a new Trigger Set by clicking NewTrigger Set in the Actions tool bar. Name
your Trigger Set and provide a description. If there are other Trigger Sets already
configured, you have the option to copy an existing Trigger Set.
3. Click Add and Edit after naming your new Trigger Set.
4. The Edit Rules window, shown in Figure 63, is where you will combine Actions,
Settings, Data Fields, and Active Paths to create a Trigger Set.

FIGURE 63. Reviewing current Trigger Sets

140
Creating your first WebNative Venture Trigger Set

5. Use the On Failure email pop-up list to select one of the Actions you previously
configured.
6. Use the Add Data Field pop-up to select your test_approval Action and click the Add
button.
7. Used the Triggered by pop-up to select a Trigger. (In this example, we’ve used Change
To.)
8. Seat a Value using the pop-up list. (In the example, we’ve used Yes.)
9. Select copy in the Run Action column, then copy to my folder in the with Setting
column.
10. Select Exit and Notify in the On Failure column.
11. To add a second Action to this rule, click the + sign to the right of the On Failure
column. This adds another Action which will be run after the first action completes
successfully.
12. Select email in the Run Action column, then Notify Me in the
with Setting column.
13. Finally, select Exit and Notify in the On Failure column. Our example looks like
Figure 64.

FIGURE 64. Example Trigger Set watching the Data Field, test_approval.

You can read this Trigger Set as follows:

For Data Field test approval, when it is Changed To Yes, copy the file using the setting
copy to my folder, and Exit and Notify if the copy fails. If it succeeds, then send email
using setting Notify Me, and Exit and Notify if sending email fails.
14. Click Save to save your Trigger Set.

141
 Chapter 13: Actions and Trigger Sets quick-start guide

Setting an Active Path

15. Add an Active Path now. (See “Definitions” on page 137 if you don’t remember what
this is.) Click the pencil in the Active Paths list. This will open the Edit Active Paths
window, shown in Figure 65.

FIGURE 65. Adding an Active Path

Please note:
• Any time Active Paths is set as Null Path, the Trigger Set will not run any Actions.
• Your Active Paths for the action must exist on WebNative Venture database-enabled
volumes.
16. Adding an Active Path resembles adding a Volume for a WebNative Venture user.
Select the Web-Enabled volume from the Volume list, and, if you wish, select a Sub-
Folder of that Volume.
17. [optional] To add a second Active Path to this Trigger Set, click the + sign on the right
side of the Active Paths list. To remove an Active Path from this Trigger Set, click the
trash can next to the path.
18. To save your Active Paths for this Trigger Set, click Save.
19. Click Edit Rules.

142
Creating your first WebNative Venture Trigger Set

This will return you to your Trigger Set configuration.

FIGURE 66. Adding an Active Path, contd.

20. Verify that your Trigger Rules and Active Paths are set correctly. Then, click Dismiss to
return to the Trigger SetTrigger Set Summary page, which should look similar to
Figure 67.

FIGURE 67. Adding an Active Path, contd.

Note that:
• In the Summary view, you will see the name of your Trigger Set, its description, and
the Active Paths for this Trigger Set. Clicking the name of the Trigger Set takes you
to the Edit Trigger window for that Trigger Set. Clicking one of the Active Paths
takes you directly to the Edit Active Paths window for the Trigger Set.
• In the Active Paths view, the Trigger Sets are sorted by the Active Paths. When you
have an extensive list of Active Paths with different Trigger Sets, this view will
allow you to quickly sort all of the Active Paths to get an idea about which Actions
may be initiated from each location.

143
 Chapter 13: Actions and Trigger Sets quick-start guide

• In the Trigger Set Summary, you will see a list of all of the Trigger Sets installed on
the system. You can change the display of information using the View By pop-up list.
You may display a Summary of all Trigger Sets organized alphabetically by name, a
summary of Active Paths in alphabetical order, or a Detailed view of all Trigger Sets
alphabetized by Trigger Set name.

Testing the Trigger Set Now, test the Trigger Set:

1. Click Change User in the Actions tool bar and log in as a user who has access to both the
Active Path for the Trigger Set and the test approval field in his or her PermSet.
2. As that user, find an image and show details by getting Image Info about that image.
(That process varies, depending on the style and view options set.) Change the value of the
test approval field to Yes, and click Save Changes.
First, WebNative Venture will copy the file to the folder you selected in the copy to
my folder settings. Then, you should receive an email from your server at the address
you configured in your Action Settings.
Because you selected Fail in the copy to my folder settings, if a file or folder with
the same name as your file already exists in the copy destination, the copy Action will
fail. In this case, because you selected Exit and Notify in your On Failure options, you
should receive email based on the settings Notify Me Fail in this case.
3. To test this, try changing the value of test approval to No and save your file. There are
no Trigger Rules associated with this change, so no Actions will run.
Change the value back to Yes, and save your changes again. This time, the same Action
will run as before. If you have not removed the file from the destination set in copy to
my folder, the copy Action will fail and notify you via email.
You can find logging information for these Actions in: /var/adm/appletalk/triggers.log
on Unix systems and C:\Program Files\Xinet\FullPress\trigger.log on Windows systems

Removing Trigger Sets Trigger Sets and their Trigger Rules are easily removed, using the Edith Trigger Set GUI, as
and their Trigger Rules shown in Figure 68. To remove and entire Trigger Set, select it in the Trigger Set pop-up list

144
Removing Trigger Sets and their Trigger Rules

and then click on the Delete Trigger Set button. To remove a Trigger Rule without removing
the entire Trigger Set, click on the trash icon next to it in the Trigger Rules table.

FIGURE 68. Removing Trigger Sets and their Trigger Rules

145
 Chapter 13: Actions and Trigger Sets quick-start guide

146
 Planning a WebNative Venture Trigger Set

Chapter 14

Trigger Set Configuration

This chapter describes the process of setting up Trigger Sets in WebNative Venture in more
detail than the “Actions and Trigger Sets quick-start guide” on page 137 and contains explanations
about configuring each of the Actions that ship with WebNative Venture.

If you haven’t already reviewed the quick-start guide, start there. For information about
writing custom Trigger Sets, refer to the “Trigger Set Customization” on page 167.

Planning a WebNative Before actually implementing a WebNative Venture Trigger Set, consider where the data-
Venture Trigger Set base can best drive automation in your workflow. In some cases, this may be as simple as
automatically sending an email message or printing a file, while in other workflows, an
elaborate series of actions may be spawned from a single database change. To work effec-
tively, Trigger Sets must be carefully planned and implemented to solve specific workflow
problems or bottlenecks. Because some Actions make changes to the server file system and
file-system changes can trigger other Actions, be cautious when adding a Trigger Set that there
are no unintended consequences.

How do Trigger Sets There are three ways that the database will initiate Actions from a Trigger Set:
actually work?
• A Value Trigger runs Actions whenever a value change in the database meets the criteria
set in the rule. For example, a user changes a data field value from Not Approved to OK
using a pop-up menu and submits the change from a browser. After updating the data-
base with the new information, WebNative Venture will check the configured Trigger
Sets to see if any are set to occur when the field value changes to OK or when the value
changes from Not Approved. The change to that field is what will cause the Trigger
Rules (if any qualify) to run their Actions.
• A Date Trigger runs Actions when a certain time-based condition is met. For example, if
a field named Due Date is set to 9:30, and there is a Date Trigger configured to run
Actions when the time reaches one hour before the time in Due Date, then at 8:30 this
trigger will run its Actions.
• A File Event Trigger runs Actions upon changes to the file system which effect a file’s
history. You can have WebNative Venture tie any of the following file-system changes
within the Active Path to fire a Trigger:
New File A file previously unknown to the database arrives inside the Active
Path
Delete A file is deleted from within the Active Path
Download High Res A high-resolution image is downloaded from the Active Path
through WebNative
Download FP0 An FPO is downloaded from an Active Path through WebNative
Preview Viewed A WebNative user previews a file within an Active Path
Upload A user uploads a file to an Active Path on the WebNative server. If
set up, this may also trigger a New File event.

147
 Chapter 14: Trigger Set Configuration

Image Order A user uses the WebNative Custom Image Order CGI on a file in
the Active Path
Move Into A user moves a file into a folder within an Active Path from a place
in the file system that is not within that Active Path
Figure 69 presents some examples of File System Triggers:

Event Triggers within an Active Path

TOP LEVEL OF A
WEBNATIVE VENTURE
VOLUME

Moving a file
here will fire
Move Event Trigger
but not New Event Moving a file
Trigger here will not fire
Event Trigger

ACTIVE PATH
Uploaded file
will not fire an
Upload nor
New File
Event Trigger

Deleting a file
here will
fire a Delete
Event Trigger Deleting a file
here will not
fire a Delete
Uploaded file Moving a file Event Trigger
will fire an Upload here will not
and New File fire a Move
Event Trigger Event Trigger

FIGURE 69. Some File Event Triggers

Each type of trigger is useful in different scenarios. If you require immediate feedback
about a change in the database, such as Approval Status, then a Value Trigger Rule is best
for monitoring that change. If you want to have things occur at a certain time, such as 90
minutes before the file is due at the press, send it via FTP, then a Date Trigger Rule will be
appropriate. If you want a change within the file system to initiate some further action, for
example, a WebNative user uploads a file, then a File Event Trigger is appropriate.

File Events either occur or they don’t. You don’t need to narrow down their trigger points.
When the Event occurs, WebNative Venture will run the associated Actions. For Date and
Value Triggers, however, you must set some conditions. Once established, the database will
verify that the conditions in the rule are met. If they are, then the associated Actions will run
following the sequence as listed in the WebNative Venture Administration GUI.

No matter how it is triggered, after each Action finishes, it will return information about
whether it ran successfully. When the Action finishes successfully, WebNative Venture will
execute the next action in the Trigger Rule. The administrator must specify, when configuring
Triggers and Actions, what WebNative Venture should do should an Action fail. The nativead-
min GUI presents three possibilities:

148
 Creating Settings for Actions

• Continue
• Exit and Notify
• Exit

If the administrator chooses Continue for the Rule, the next Action (if any) will execute
regardless of the success of the previous Action. If the administrator chooses Exit or Exit
and Notify, the Trigger Set will not run any further Actions. Exit and Notify will also send
email using the On Failure email settings for the Trigger Set.

Creating Settings for To add a Setting to a specific Action:

Actions
1. Click on the Action tab in the Administration GUI. You’ll see a summary of current
actions on your server, similar to Figure 70 below:

FIGURE 70. The Action summary page

You may now either click New Setting in the Actions tool bar or click on the name of the
action in the Actions summary window. You should see a window similar to Figure 71

149
 Chapter 14: Trigger Set Configuration

where you can add new settings to Actions Please keep in mind that WebNative Venture will
autosave setting here if you leave the screen to do something else.

FIGURE 71. The New Settings window

List of Actions This section provides details about each Action Xinet ships with WebNative Venture.

archive

The archive Action adds the file/directory to the selected FlashNet schedule. If FlashNet
and FlashWeb are not installed on your system, you won’t see any schedules in the configu-
ration window for this action. If FlashNet and FlashWeb are installed on your system, the
list you see will have been generated from the schedules configured in the FlashWeb Plu-
gins Configuration GUI. If you wish to configure schedules that are only accessible for use
in Trigger-driven workflows, create a new WebNative user named xfnaction, and assign
those schedules to this user. The list of installed schedules you see for the archive Action
will include schedules that are not restricted to specific users, plus those created only for
user xfnaction.

compare

The compare Action is used with a date trigger to determine if the action selected in a Trig-
ger Set should be executed or not. All current WebNative Venture metadata fields will be
available for selection in the compare configuration screen. Select the appropriate field and
configure it by entering a value for the field that will be the basis for comparison.

If you are working with Boolean fields, for instance, you would make a compare setting in
which the Boolean Yes/No field is set to Yes. Later, in the Trigger Set, you will specify the
compare setting to be used as a test to determine if a rule that follows it will be run or not.

150
List of Actions

For example, if a date trigger is used to archive a file, you may wish to first check the value
of a boolean metadata field. In this example, the rule will only be executed if the Boolean
Yes/No field is set to Yes. If the test succeeds, then the archive can proceed; if the test fails,
then the archive action will not be run. In this way,
compare is used with date triggers to make decisions based on existing metadata values.

copy

The copy Action copies the file/directory to the location specified in the Destination field of
the setting. Both absolute and relative paths may be used to specify destinations, but the
destination directory must already exist for the action to succeed. If the copy Action
attempts to copy a file or directory to a location that does not exist, it will exit as failed and
the failure case in the Trigger Set (Continue, Exit, Exit and Notify) will apply.

On Windows systems, please avoid using exclusively relative paths. If you try to use one,
files will not end up where you want them. For example, the path ..\ would fail, while
..\old\ would work. In other words, any relative path must include a string as part of the
relative path.

The Overwrite/Append/Fail option determines what the behavior will be if there is already
a file or directory in the location with the same name as the file the Action is attempting to
copy. In the case of Overwrite, the Action will automatically remove a file with the same
name that exists in the destination location before copying the file/directory. If a directory
with the same name already exists in the destination, the Overwrite option will not delete it
automatically as a safety precaution. In this case, the same behavior as in Append will
occur. In the case of Append, the action will automatically rename the file to add a unique
sequential number when it copies the file. If a myfile.tif already exists in the destination, the
action will make a copy of the file named myfile.tif.1 in the destination when Append is
selected. If Fail is selected, the action will fail and the failure case in the Trigger Set (Con-
tinue, Exit, Exit and Notify) will apply.

email

The email Action provides more opportunity for customization than any other Action
shipped with WebNative Venture. There are several variables that will be useful for creating
informative email messages. This Action is also used to notify users when a Trigger Set
Action did not complete successfully. Though it is not necessary to “tokenize” these vari-
ables by including them in curly brackets ({}), Xinet recommends you do so for consistent
results.

The email messages may use the following variables:

$FILENAMEThis is the UNIX-style pathname (using forward slashes, even on Windows sys-
tems) to the file that initiated the email.

$HTMLPATHNAMEThis is the HTML path as to the file in ${FILENAME} as it would appear in

the navigation bar of a WebNative Venture window.

$URLPATHNAMEThis is also the path to the file in ${FILENAME}, but in a format suitable to
create a link in the body of an email.

151
 Chapter 14: Trigger Set Configuration

$USERNAME If a Value Trigger initiates the Action, this is the user who made the data field
change. When a Date Trigger initiates the Action, this user will be DateTriggerUser.

$TYPEThis is the file type information from the Macintosh resource for the file that has the
associated data field. You can see this information about the file using /usr/etc/appletalk/
kats on the UNIX command line, or on Windows systems, using
C:\Program Files\Xinet\FullPress\kats. You can also use ResEdit from a Macintosh client.

$CREATORThis is the creator information from the Macintosh resource for the file that has
the associated data field. You can see this information about the file using kats on the com-
mand line as described above, or ResEdit from a Macintosh client.

All keywords that have values assigned for the file may also be used as variables in the
email Action, for example:

$KEYWORD<number>_VALUE=<keyword number from WebNative Venture>

$KEYWORD<name>_NAME=<keyword name from WebNative Venture>

The keyword numbers can be associated with their names by viewing the data field infor-
mation in the WebNative Venture Administration GUI > Data Fields > Edit Data Fields sub-
panel. The Localized Name Variable will contain the keyword number. The keyword name
is the name as it appears in the pull-down menu in the same subpanel.

For example, if you have a Boolean data field named on or off that has a localized name
value of lang.keyword60, then the variables to show the name and value of this field would
be $KEYWORD60_NAME and $KEYWORD60_VALUE, respectively.

Some variables are set after the Action runs. The most useful of these when creating a mail
message are:

$XFILESHORT This is only the filename itself, without any path information.

$XKEYThis is the name of the keyword used to initiate the action.

On Unix systems:

There are also two variables that may be useful to the administrator when initially setting up
an email Action setting. They are only provided for debugging and troubleshooting.

$ALLENVVARSThis is a list of all environment variables and their values, including the
$KEYWORD<number>_NAME values.

$ALLEXEVARSThis is a list of all arguments used to execute the Action itself. This is most
useful for troubleshooting why an Action behaved in an unexpected manner.

ON WINDOWS SYSTEMS: There is also a variable that may be useful to the administrator
when initially setting up an email Action setting. It is for debugging and troubleshooting
only. Namely, if the subject line exactly matches ALLENVVARS, then the output of set will be
appended to the file. So, to get a full list of variables in use, create a new setting with sub-
ject line ALLENVVARS.

152
List of Actions

ON ALL PLATFORMS: To create a mail message that uses these fields, you can put something
similar to the following in the Body field of the Action setting:
The file “${XFILESHORT}” has had “${XKEY}” changed or updated
by ${USERNAME}. The value of ${KEYWORD65_NAME} for “${XFILE-
SHORT}” is ${KEYWORD65_VALUE}. You can see this file for your-
self at:
http://server.domain.com/webnative/imageinfo?${URLPATHNAME}.
Sincerely,
Your server

These variables may also be used in the Subject field of the email setting.

ON UNIX SYSTEMS: On Sun, the default sender of email is nobody. On Mac OSX and SGI,
the default sender of email is root. To change these, you may edit the email Action itself,
which is located in /usr/etc/webnative/actions/email/email. For the platform specified in
the action, change the line:
set sender = "nobody"

or
set sender = "root"

to read:
set sender = "<username>"

This must be an actual UNIX user on the system.

ON WINDOWS SYSTEMS: On Windows systems, if you want to change the sender email, edit
the batch file:
SET XFROM=WNVadmin@domain.com

Change WNVadmin@domain.com to some real address. Please note: You should not include
“spaces” either side of the = sign.

move

The move Action moves the file/directory to the location specified in the Destination field of
the setting. Both absolute and relative paths may be used to specify destinations, but the
destination directory must already exist for the action to succeed. If the move Action
attempts to move a file or directory to a location that does not exist, it will exit as failed and
the failure case in the Trigger Set (Continue, Exit, Exit and Notify) will apply.

On Windows systems, please avoid using exclusively relative paths. If you try to use one,
files will not end up where you want them. For example, the path ..\ would fail, while
..\old\ would work. In other words, any relative path must include a string as part of the
relative path.

The Overwrite/Append/Fail option determines what the behavior will be if there is already
a file or directory in the location with the same name as the file the action is attempting to
move. In the case of Overwrite, the action will automatically remove a file with the same

153
 Chapter 14: Trigger Set Configuration

name that exists in the destination location before moving the file/directory. If a directory
with the same name already exists in the destination, the Overwrite option will not delete it
automatically as a safety precaution. In this case, the same behavior as in Append will
occur. In the case of Append, the action will automatically rename the file to add a unique
sequential number when it moves the file. If a myfile.tif already exists in the destination, the
action will rename the moved file myfile.tif.1 in the destination when Append is selected. If
Fail is selected, the action will fail and the failure case in the Trigger Set (Continue, Exit,
Exit and Notify) will apply.

print

The print Action submits the file/directory to the selected print queue. If the file is “unprint-
able,” such as a directory or native QuarkXPress document (the server won’t have the nec-
essary QuarkXPress application for producing PostScript), the action will still tell the
Trigger Rule it was a success because it was able to deliver to the queue. If the action tries
to print to a queue that no longer exists—perhaps it was deleted from the server after the
settings were saved—then the Action will return an error.

The print Action successfully handles PDFs, most image types, and of course PostScript
files.

remove

The remove Action removes the file from the file system. If the move Action is executed rel-
ative to a directory, then it will exit with an error. The remove Action will not automatically
remove directories as a safety precaution.

setdatafield

The setdatafield Action, when triggered, changes the value of a Data Field. To avoid loop-
ing or other unexpected activity, WebNative Venture prevents changes to metadata that
were caused by the setdatafield Action from inciting other Actions.

transfer

The transfer Action is used to transfer files to remote servers over FTP or HTTP using the
curl(1) binary included with FullPress. To learn more about using cURL (Client for URLs),
visit the website at http://curl.haxx.se/.
Before configuring the transfer Action, be sure that you are able to successfully transfer
files using curl on the command line. This will help you work out any potential problems
with file transfer, such as FTP Host name (or IP address) or password problems, before add-
ing automation. Also, be aware that when using curl(1) to transfer files, it uses relative
paths to access the upload directory. If you usually enter:
% cd /public

when using an FTP client to transfer files to/from a site, you will need to take note of the rel-
ative path you would use to get to /public, such as:
../../public

154
 List of Actions

Using curl(1) for transfer also allows you to use either HTTP or FTP to transfer files; but,
please remember: if you cannot get the transfer to work from the command line, it will not
work when you add it to a Trigger Set.

movetree

This movetree Action shuttles files and directories between one path in the file system and
another, maintaining any underlying directory structure throughout operations. This is use-
ful for archive-to-disk implementations where you want to move a set of data from a live
production area to an “archive” area, then sometime later, copy it back. (“Archiving to disk
using the WebNative Suite” beginning on page 81 provides more information about
archive-to-disk strategies.)

The movetree Action requires two arguments: namely, the two paths between which you
want to move a tree of directories and subdirectories. Figure 72 shows how you specify the
paths:

Specifies the top level of the

“active” file tree structure where,
typically, files will be edited.
Multiple copies of the tree will
never be stored here.

Specifies the “resting” location

to which movetree will copy the
file tree stucture specified in the
Movepath type-in box. Multiple
versions of the tree may be stored
here.

FIGURE 72. Setting up a movetree Action

How the movetree Action works:

• When triggered, the movetree Action determines whether it has been triggered from the
Copypath or the Movepath. What it does varies accordingly.
• If it is triggered from the path you specified in the Movepath type-in box, it copies the
directory structure into the Copypath location by substituting the path in the Copypath
box for the one in the Movepath box.
After successfully copying all the files, the Action removes the original files from the
Movepath, leaving that location empty for the time being. (Coping first, then verifying
success before removing the files, rather than simply moving them, ensures that no data
will be lost should something go wrong during the transfer.)

155
 Chapter 14: Trigger Set Configuration

If the destination already exists in the Copypath location, the movetree Action will
append increasing integers to the destination until the path becomes unique—in effect,
implementing a versioning strategy.
• If the movetree Action is triggered within the path in the Copypath box, it will copy files
from that Copypath location to the Movepath location, with one major exception: if the
path already exists in the Movepath location, the Action will fail; thus, preventing unin-
tented workloss caused by overwriting.
• If a movetree Action were to be triggered within an area that does not start with either
the specified Movepath or Copypath, it would fail.
In addition, if either the Movepath or Copypath were to lie outside of the Trigger Set’s
Active Path, the movetree Action could not take place. Both paths must be included
within the Trigger Set’s list of Active Path(s).

Figure 73 illustrates some of these points.

The movetree Action

The movepath location The copypath location

then deleted from the move

ed, v erified, path
e c opi loca
tion
e tre
F il
ssible versioni
with po ng.
M M1 M
es n’t
File t do
tree copied if i
already exist.

ACTIVE PATH ACTIVE PATH

FIGURE 73. Overview of the movetree Action

An example: archiving to disk

Suppose you wanted to set up an archive-to-disk procedure that allowed users with appro-
priate permissions to move directory trees between a “live” path and a disk where archives
were stored. The following steps would set up such a mechanism.

156
 List of Actions

1. Establish a Data Field called archive-restore which will provide users a checkbox in
Image Info that allows them to move files between the archive and live areas:

FIGURE 74. Adding a boolean Data Field to trigger archiving to disk and restoration

2. Add the new Data Field to a template and assign it to appropriate users.
This will allow personnel with appropriate Userperms to see something similar to
Figure 75. Once you’ve finished setting up the Trigger and Action, changing this piece
of metadata allows them to move file trees between the archive and live path and vice
versa.

If the assets in question have

been archived, selecting the
check box will trigger restora-
tion. Likewise, if the assets are in
the live area, selecting the
checkbox will trigger archiving.

FIGURE 75. An Image Info window allowing archiving to disk and restoration

157
 Chapter 14: Trigger Set Configuration

3. Set up a movetree Action as shown in Figure 76, providing both Movepath and
Copypath locations.

FIGURE 76. Setting up a movetree Action

4. Create a Trigger Set using the archive-restore Data Field from Step 1. Be sure to set
both the Copypath and Movepath locations as Active Paths, as shown in Figure 77.

FIGURE 77. A Trigger Set that runs movetree

This was the final step in the archive-to-disk set. This mechanism will always restore
files to the place in the file system from which they were originally archived. If you
would like to restore files toan alternative location, continue with the step below.
5. [optional] If you wish, you could set up a second Data Field and movetree Action that
would move files from the archive location to a different path than the one where it
originally resided. Continuing the example above—where we’ve just set changes to the

158
 Using Trigger Sets

archive-restore Data Field to move files between /space/movetree-live and /space/

movetree-archived—we could create a second Data Field for the Image Info dialog,
called archive-alt-restore, which could be set to move files between /space/movetree-
archive and /space/movetree-alt-restore, in effect implementing a restore-to-alternative-
path archive-to-disk. strategy that once again would maintain a versioning system
within the /space/movetree-archive path.

FIGURE 78. Using a second movetree Action to restore to an alternative path

Using Trigger Sets For a quick summary of setting up an Trigger Set, see “Actions and Trigger Sets quick-start
guide” on page 137.

The following steps provide a survey of the Actions subpanels used in Trigger Set configu-
ration. Following these should give you a general idea about how to work with Trigger Sets:

159
 Chapter 14: Trigger Set Configuration

1. In the WebNative Venture Administration GUI, click on the Actions tab. As Figure 71 on
page 150 shows, the subpanels are Actions, New Setting, Edit Setting, Trigger Sets, New
Trigger Sets and Edit Trigger Set.
The first subpanel, Actions, shown in Figure 79, gives a list of all actions installed on the
system and any settings that have been created for those Actions.
Individual nativeadmin-
established settings

WebNative
Venture Actions

etc.

FIGURE 79. The Actions summary subpanel

160
Using Trigger Sets

2. To add a new setting for a specific Action, click on the New Setting subtab . This will
open the New Setting. In the example shown in Figure 80, we see the New Setting
subpanel for the copy Action.

FIGURE 80. The New Setting subpanel for the copy Action

You’ll use the New Setting subpanel to add a New Setting for any Action. Simply select
the Action you want from the Action pop-up list. Each Action has specific requirements
to customize its execution. Refer to the more detailed information about Actions in “List
of Actions” on page 150 for more information about what to expect.
3. Click on the Trigger Sets subtab. The subpanel presents different views of the Trigger
Sets configured on your system. Use the pop-up menu shown in Figure 81 to switch
between different views.

FIGURE 81. Switching between ways to view Trigger Sets

The Trigger Set Summary presents a list of all of the configured Trigger Sets sorted
alphabetically by the Trigger Set name. The description of the Trigger Set and its Active
Paths are included in this view.
The Trigger Set Active Paths view shows the same data as the Trigger Set Summary
window, but sorts the information alphabetically by the Active Path. This view is
supplied to assist with troubleshooting the system if an Action occurs unexpectedly or in
an unexpected path. The Trigger Set Active Paths subpanel will also make it easy to
determine if multiple Trigger Sets are active for the same path.

161
 Chapter 14: Trigger Set Configuration

The Trigger Set Details view provides a summary of all actions that occur inside an
Trigger Set. Again, this overall view of all Trigger Set Trigger Rules is provided for
administrator reference and to assist troubleshooting.
From any of the Trigger Set views, you can edit the Trigger Set by clicking on its name
in the list. Active Paths for a Trigger Set may also be edited by clicking on the path in
the Trigger Set Summary and Trigger Set Active Paths views.
4. To add a new Trigger Set, click on the New Trigger Set subtab. You’ll see a window
such as the one in Figure 82.

FIGURE 82. Adding a new Trigger Set

5. You will first need to name your new Trigger Set. This name can not be changed after
you save the Trigger Set.
6. Add a useful description for the Trigger Set as well. Unlike the name, the description
can be changed after your initial creation of the Trigger Set.
7. If it’s more convenient, use the Copy Trigger Set pop-up menu to specify an existing
Trigger Set to copy. If you copy an existing Trigger Set, the Trigger Rules and Actions in
your Trigger Set you are building will be copied from the selected Trigger Set in the
pop-up list. The Active Paths, however, will not be copied to make sure you do not
inadvertently have two Trigger Sets performing precisely the same Actions in the same
locations.

162
Using Trigger Sets

8. Click the Add and Edit button so you can configure your Rules for your Tigger Set. A
window similar to the one below will open. This is where you configure your Rules.

FIGURE 83. Configuring Rules for Trigger Sets

9. [optional] Select an email setting from the On Failure email pop-up list to establish
where WebNative Venture will send notification if any Action in the Trigger Set fails to
execute properly. This setting will be used if you opt to Exit and Notify when
configuring Actions for a Trigger Rule.
10. [optional] Add a new data field to the Trigger Set by selecting the data field from the
Add Data Field pop-up menu. Then click Add. The new field will appear in your list of
Trigger Rules so you can establish appropriate parameters for it.
Trigger Rules are comprised of:
• The Data Field or File Event
• Condition upon which to run the Action(s) (Triggered by)
• [optional] The Value that release the Trigger
• The Action to run
• Its Settings
• What to do if the Action fails.
If the Data Field you added to the Trigger Rules has a data type of Date, then the
Triggered by options will be relative to the value of that field. These Date Triggers will
execute Actions at specific times.
For example, you could create a Data Field within WebNative Venture called
Timestamp with a data type of Date. You could then create a Trigger Set to execute some
Action at some specific date/time, e.g., at a week before, at 12 hours after, etc.
If the Data Field does not have a data type of Date (i.e. Text, Integer, Floating Point, or
Boolean), Actions will only be triggered by Any Change, Change To, or Change From.

163
 Chapter 14: Trigger Set Configuration

Any Change, will execute the Actions in the Trigger Rule if any change occurs to the
value of the Data Field. Change To, will execute the Actions when the value is changed
to match the entry in the Value column. Change From, will only execute the actions if
the Data Field previously contained the entry in the Value column and has been changed
to a different value.
If multiple Trigger Rules within a single Trigger Set match a condition, both of these
Trigger Rules will execute their Actions. For example, if you configure a Trigger Rule to
execute when a boolean field Approved changes to Yes, and you configure another
Trigger Rule to execute when the same boolean field is changed from No, then BOTH
Trigger Rules will execute their Actions concurrently when the field is changed to value
Yes.
Each Trigger Rule may execute multiple actions in sequence. For example, if you want
to send an email and then transfer a file via FTP to a remote server from a single change
in WebNative Venture, first add the email Action and its settings to the Trigger Rule.
Then, click the + sign next to the Trigger Rule to add another action to the Trigger
Rule. If you want to run an Action between two previously configured Actions, click the
+ sign to the right of the first of these Actions. The new Action will insert between the
two.
To remove an Action from a Trigger Rule, click the trash-can icon next to that Action. To
remove a Trigger Rule, first remove all Actions from the Trigger Rule. Then, click the
trash-can icon next to the Trigger Rule.
11. When you first create a Trigger Set, the Active Paths will be “null.” This Trigger Set will
never execute Actions if the Active Paths are “null.” Therefore, to activate your new
Trigger Set, you must specify Active Paths. Only database fields or file system events
for files that exist within those Active Paths will qualify to execute the Trigger Rules
within the Tigger Set.
To add Active Paths to the Trigger Set, click on the pencil icon in the Active Paths
section of the Edit Trigger subpanel. This new window, shown in Figure 84, will allow
you to assign as many Active Paths as you wish to your new Trigger Set:

FIGURE 84. Assigning active paths to a Trigger Set

Use of the Active Paths window resembles WebNative Volumes administration. First,
select a volume in the Volume column. After you have selected the volume, use the
Active Folder list to select a subdirectory of that volume. Click Save to save your

164
 Logging for Trigger Sets

changes. You may add more Active Paths to the Trigger Set by clicking the + sign next
to the last path in the Active Paths list. To delete an Active Path, click the trash-can icon
next to that Active Path.

Logging for Trigger Sets On UNIX systems, you will find logging information for Actions is in:
/var/adm/appletalk/triggers.log

On Windows systems, logs are in:

\Program Files\Xinet\FullPress\trigger.log

WebNative Venture limits the text area scroll box to 32 k, so the log will only post the last
31.5 k of the file.

165
 Chapter 14: Trigger Set Configuration

166
 Some details about Trigger Sets

Chapter 15

Trigger Set Customization

Some details about Triggers and Actions depend upon the idea that a change in the WebNative Venture database
Trigger Sets or an Event within the File System has the power to initiate an Action (or series of Actions),
such as transferring a file, printing a file, etc. This provides a flexible and powerful opportunity
to build many specific workflows. Figure 85 provides an overview of Date and Value
Triggers and Actions. Figure 86 provides an overview of File System Event Triggers and
Actions.

Set a Value.

Exit
Is a Trigger Set N without
associated with any Action.
it?

Exit
Is an Active Path N without
associated with any Action.
it?

What kind Date

of Field was Determine the correct
changed? execution times.

Value
Add Actions in list to
execute later.*

Execute Actions.

* The dblogd demon reads

Exit this list periodically and
executes those Actions at
the correct time.

FIGURE 85. Overview of how Date/Value Triggers and Actions work.

167
 Chapter 15: Trigger Set Customization

File System
Event occurs*

Exit
Is a Trigger Set N without
associated with any Action.
it?

Exit
without N Is an Active Path
any Action. associated with
it?

Execute Actions

* The dblogd demon

Exit watches for changes
in the File System and
logs these Events.

FIGURE 86. Overview of how File System Event Triggers and Actions work

As is briefly covered in “Trigger Set Configuration” in the WebNative and WebNative Ven-
ture Administration Guide, there are three types of triggers: file Event Triggers Date Trig-
gers and Value Triggers.

A File Event Trigger runs Actions upon changes to a file inside an Active Path. The
changes, which all effect a file’s history, include downloading a high-resolution version of
the file, downloading an FPO version of a file, uploading a new file, downloading a Custom
Image Order, or moving a file into a watched path. You can tie any of these changes, as long
as they occur within an Active Path, to a Trigger Set with specified Actions.

Date Triggers and Value Triggers differ, in that a change in value of some piece of metadata
must occur. Though the mechanism for activating these two trigger types is slightly differ-
ent, both require that a specific condition be satisfied to execute actions. Date Triggers meet
their conditions when the current time reaches the period specified within the Action, for
example “30 minutes before the value of a date field.”

Value Triggers meet conditions through changes to values within data fields. With each
change to a database value via WebNative Venture, these changes are verified against the
configured Trigger Sets. First, WebNative Venture checks whether any Trigger Sets are
active for the file-system path for the changed file. If
WebNative Venture finds that there is a Trigger Set corresponding to the file-system path, it
then compares the change that occurred to any that might initiate actions in that Trigger Set.
Then, if there is a Trigger Rule that should be initiated by the value change, WebNative
Venture executes in sequential order the Actions associated with that Trigger Rule.

168
 Files used in Trigger Sets

Date Triggers also test whether any Rules should invoke Actions whenever values of date
fields are set. However, any Actions that should be run some time in the future (when the
correct time is reached) are added to a list in the database to be executed at the correct time.
When the condition is met (the time arrives), WebNative Venture executes the Trigger Rule
Actions.

WebNative Venture executes Actions using some information from the environment; it may
provide other information using “arguments.” Both standard arguments, discussed below,
and custom arguments are possible. Please note that custom arguments must always be
named arg0, arg1, arg2 and so on. These are the only legal names for custom arguments to
be used with Actions. Any other argument names will be ignored.

The following example shows how you might execute the copy Action with arguments:

On UNIX systems:

/usr/etc/webnative/actions/copy/copy -f /path/to/file -arg0

/path/to/destination -arg1 <O/A/F>

On Windows systems:

Program Files\Xinet\WebNative\Bin\actions\copy\copy.bat -f
/path/to/file -arg0 /path/to/destination -arg1 <O/A/F>

Files used in Trigger Sets The files and executables used with Trigger Sets reside in a few places on the file system.

The actions directory

All files used to establish Trigger Sets reside in the actions directory.

On UNIX systems:
/usr/etc/webnative/actions/name_of_action/

On Windows systems:
Program Files\Xinet\WebNative\Bin\actions\name_of_action

All files for specific Actions reside in the subdirectories of the action directory.

Action executables

On UNIX systems:
/usr/etc/webnative/actions/name_of_action/action_executable

On Windows systems:
Program Files\Xinet\WebNative\Bin\actions\name_of_action\
action_executable.exe
or
Program Files\Xinet\WebNative\Bin\actions\name_of_action\
action_executable.bat

169
 Chapter 15: Trigger Set Customization

The executable itself must have the same name as the Action directory. On UNIX systems,
there should be no extension. For Windows users, however, the Action must be named
either name_of_action.exe or name_of_action.bat when the Action has been written as
a batch script.

Action configuration files

On UNIX systems:
/usr/etc/webnative/actions/name_of_action/name_of_action.conf

On Windows systems:
Program Files\Xinet\WebNative\Bin\actions\name_of_action\
name_of_action.conf

This file is used by the WebNative Venture Administration GUI to provide input about set-
tings. As an example, let’s look at the copy Action configuration file provided with WebNa-
tive Venture:
[setup]
stdargs=f
custargcount=2
[arg0]
label=Destination (must exist)
rows=1
cols=64
type=path
[arg1]
label=Overwrite/Append/Fail
option_count=3
option_value0=O
option_name0=Overwrite
option_value1=A
option_name1=Append Unique Number
option_value2=F
option_name2=Fail

The first section, [setup], describes how the Action will be called using standard arguments.
The options include:
fidthe file ID
kidthe keyword ID
uidthe user ID
fthe full path to the file
pthe HTML path
kthe keyword that changed to initiate the action
uthe user that set the keyword value
datthe current date
newthe current (new) value
oldthe previous (old) value
typthe File Type
crethe File Creator

170
 Files used for Action GUI information

A .conf file may use any combination of these to run the Action, so long as they are comma-
separated. For an example of this, look at the configuration file provided with the email
Action.

The next option inside [setup] is the number of custom arguments that will be set in the con-
figuration file itself. In this case, there are two custom arguments, arg0 and arg1.

The next section, [arg0], provides information about the first argument. The description,
label, will appear in the WebNative Venture GUI to the left of the argument. The next two
options, rows and cols, specify that the argument input area is a text field and describe the
size of the input area in the GUI. The final descriptor, type=path, tells WebNative Venture
to protect special characters in this text area because the characters must be used later as a
file-system path. There are no other type indicators at this time, so it is only necessary to
include this option when your Action requires user input of a file-system path.

Notice how the final section, [arg1], is slightly different than the description input for
[arg0]. Though both use the label, what follows is very different. In this case, arg1 is
selected by the user using a pull-down menu in the GUI. The option_count setting tells the
GUI how many options will be in the pull-down menu. Each of the options has both a name
and a value. The option_value will be the actual argument passed to the Action at time of
execution. The option_name is the information the administrator will see in the WebNative
Venture GUI when creating settings for the Action. For example, if a user selects Append in
the administration GUI, the Action will execute with -arg1 A.

At this time, Text and pull-down are the only two options available for data input in the set-
tings window. Only appropriate text input fields should be tagged as paths.

Files used for Action On UNIX systems:

GUI information
/usr/etc/webnative/actions/name_of_action/name_of_action.desc

On Windows systems:
Program Files\Xinet\WebNative\Bin\actions\name_of_action\
name_of_action.desc

This file is used by the WebNative Venture Administration GUI to provide instructions and
helpful information at the top of the Action Settings screen. If this file does not exist, the
section of the GUI marked Description will be blank.

The Action .buildconfig On UNIX systems:

files
/usr/etc/webnative/actions/name_of_action/name_of_action.buildconfig

On Windows systems:
Program Files\Xinet\WebNative\Bin\actions\name_of_action\
name_of_action.buildconfig.exe

or
Program Files\Xinet\WebNative\Bin\actions\name_of_action\
name_of_action.buildconfig.bat

171
 Chapter 15: Trigger Set Customization

In some cases, the Action configuration file should reflect information that is unique to the
specific server running WebNative Venture. For example, the archive Action should show a
list of schedules that is accurate for the current server, and allow the administrator to choose
one. In these cases, WebNative Venture uses the .buildconfig executable to automatically
generate the name_of_action.conf file. The .buildconfig file may be written in any lan-
guage that can be executed by the server, but it must generate a properly formatted .conf file
to be useful. On UNIX systems, see the archive.buildconfig file for one example of how this
may be implemented. The .buildconfig file, if it exists, only executes when the settings win-
dow for the Action is viewed via the WebNative Venture Administration GUI.

Administrative settings On UNIX systems:

files
/usr/etc/webnative/actions/name_of_action/settings/name_of_setting

On Windows systems:
Program Files\Xinet\WebNative\Bin\actions\name_of_action\
settings\name_of_setting

All settings created by the administrator are saved inside this setting directory. They should
not be edited by hand; only in the WebNative Venture Administration GUI.

Log files On UNIX systems:

/var/adm/fullpress/trigger.log

On Windows systems:
Program Files\Xinet\FullPress\trigger.log

Most of the interesting logging for Trigger Sets goes to this file. It is a clear-text file (on
UNIX, you can easily run tail -f on this while monitoring system activity) and the file to
which, by default, all Actions are logged. When troubleshooting Trigger Sets, this is the
most useful log file. A more detailed discussion of this file follows.

Example: Customizing While you can write Actions in any executable format, modifying an Action that ships with
an Action that ships with WebNative Venture will illustrate some rules to keep in mind whether you’re customizing an
WebNative Venture existing Action or writing a new one. If you plan to write your own Actions rather than mod-
ify one that exists, please also refer to “Background for writing your own Actions” on
page 176.

In our example, we will customize the email Action so that it includes the file ID along with
the file name, the HTML path, the keyword that changed, and the name of the user trigger-
ing the email:

On UNIX systems:

1. Login as root.
2. Copy the email Action directory to a directory with a new name:
cp /usr/etc/webnative/actions/email /usr/etc/webnative/actions/
new_email

172
Example: Customizing an Action that ships with WebNative Venture

3. Connect to the new directory:

cd /usr/etc/webnative/actions/new_email
4. Then, rename the file email, for example:
mv email new_email
5. Likewise, rename the files email.bat, email.conf, and email.desc:
mv email.bat new_email.bat
mv email.conf new_email.conf
mv email.desc new_email.desc
6. Open the file new_email.conf in a text editor and add fid to the list of stdargs:
stdargs=f,p,k,u,fid.
7. Open the email script in a text editor (in our example, the file new_email) and edit the
Set the usage message portion by changing:
set USAGE = "usage: $0 -f <filename> -p <htmlpath> -k <keyword> -
u <user> -arg0 <to@mail.address> -arg1 <subject> -arg2 <path to
body file>"
So that it reads:
set USAGE = "usage: $0 -f <filename> -p <htmlpath> -k <keyword> -
u <user> -fid <fileid> -arg0 <to@mail.address> -arg1 <subject> -
arg2 <path to body file>”
8. Then search for the portion of the script that pertains to Check argument count to
confirm correct usage. Just after the four lines that define case “-u”, insert four new
lines, like this:
case "-fid":
@ i++
setenv XFID "$argv[$i]"
breaksw

On Windows:

Use the analogous methodology to modify the new_email.bat file.

General rules for modifying or writing new Actions:

1. If you are working with a UNIX server, the file, name_of_action.bat, must exist—
although when modifying an existing Action, you do not necessarily need to change the
file.
2. If you are working with a Windows server, the file, name_of_action, must exist even
though only the file, name_of_action.bat, will be used.
3. You may wish to modify the file, name_of_action.desc, in order to differentiate the
original Action for the newly-created one in the GUI.
4. When modifying an existing Action, do not simply edit it. Always make a copy to edit
because Actions with the same name as those that ship with WebNative Venture may be
overwritten when you install future versions of WebNative Venture.

173
 Chapter 15: Trigger Set Customization

Troubleshooting If your Actions are not running, there are several things that can be done to determine the
WebNative Venture source of the problem:
Trigger Sets
1. Make sure that dblogd is running using one of the following methods:
UNIX:ps -ef | grep dblogd
OS X:ps -awux | grep dblogd
Windows:check the Task Manager for the dblogd.exe process
If the database daemon is not running, Actions will not be run. Restart dblogd using the
WebNative nativeadmin GUI > Database > Daemon > Start Daemon button and try the
Action again.
2. Verify that you are making the metadata change in the active path for the Trigger Set
containing the Action you want to run. Check the active path for your Trigger Set in
WebNative nativeadmin GUI > Actions > Trigger Set > (Select Trigger Set).
3. Check the venture.log file for any errors pertaining to the database, Trigger Set, or
particular action. Use your favorite text editor to view the log file which can be found in
the following locations:
UNIX:/var/adm/appletalk/venture.log
Windows:Program Files\Xinet\FullPress\venture.log
Any errors in this log regarding corrupt tables, or errors from running Actions should be
reported to Xinet Technical Support.
4. Check the trigger.log file for any errors about the action. Generally, if an Action cannot
run, the error will show up in this log, along with an error code. The log can be found in
the following locations:
UNIX:/var/adm/appletalk/trigger.log
Windows:Program Files\Xinet\FullPress\trigger.log
and the error may look something like this:
[Tue Jun 1 15:43:38] About to execute [/usr/etc/webnative/
actions/email/email]
[Tue Jun 1 15:43:39] *** Return: [1]
One method of troubleshooting errors is to run the Action script on the command line.
Should you discover that an Action runs properly on the command line, but fails when
run by a WebNative Venture Trigger Rule, you should contact Xinet Technical Support
for assistance.

Advanced For server administrators who have advanced understanding of WebNative Venture Trig-
troubleshooting of gers and Actions, this section delves into the structure and information found in the trig-
WebNative Venture ger.log file.
Triggers and Actions
The trigger.log file will give a list of the variables used in each attempt to run an action, and
that data can be used to exercise the action before implementing it in a workflow or trouble-
shooting why an action may not be behaving as expected.

Your log should look something likes this:

174
 Advanced troubleshooting of WebNative Venture Triggers and Actions

[Tue Jun 1 15:43:38] ARG[0]=/usr/etc/webnative/actions/

email/email
[Tue Jun 1 15:43:38] ARG[1]=-f
[Tue Jun 1 15:43:38] ARG[2]=/raid/testfiles/file.eps
[Tue Jun 1 15:43:38] ARG[3]=-k
[Tue Jun 1 15:43:38] ARG[4]=CheckBox
[Tue Jun 1 15:43:38] ARG[5]=-u
[Tue Jun 1 15:43:38] ARG[6]=demo
[Tue Jun 1 15:43:38] ARG[7]=-arg0
[Tue Jun 1 15:43:38] ARG[8]=sysadm@xinet.com
[Tue Jun 1 15:43:38] ARG[9]=-arg1
[Tue Jun 1 15:43:38] ARG[10]=Regarding your action
[Tue Jun 1 15:43:38] ARG[11]=-arg2
[Tue Jun 1 15:43:38] ARG[12]=/usr/etc/webnative/actions/
email/settings/Demo_Email.arg02
[Tue Jun 1 15:43:38] ENV[0]=FILENAME=/raid/testfiles/
file.eps
[Tue Jun 1 15:43:38] ENV[1]=URLPATHNAME=/raid/testfiles/
file.eps
[Tue Jun 1 15:43:38] ENV[2]=HTMLPATH-
NAME=raid:testfiles:file.eps
[Tue Jun 1 15:43:38] ENV[3]=USERNAME=demo
[Tue Jun 1 15:43:38] ENV[4]=TYPE=8BIM
[Tue Jun 1 15:43:38] ENV[5]=CREATOR=EPSF
[Tue Jun 1 15:43:38] ENV[6]=KEYWORD60_VALUE=1
[Tue Jun 1 15:43:38] ENV[7]=KEYWORD60_NAME=T/F
[Tue Jun 1 15:43:38] About to execute [/usr/etc/webnative/
actions/email/email]
[Tue Jun 1 15:43:39] *** Return: [0]
[Tue Jun 1 15:43:39] *Action Succeded! (estatus=0) Continu-
ing...
[Tue Jun 1 15:43:39]<<ACTION: ruleid[10], action[email],
setting[Demo_Email], fname[/raid/testfiles/file.eps],
newval[1], oldval[0]

This shows that the setting Demo_Email was run when the value of the CheckBox data field
was set to checked; 1 represents the positive value, while 0 is the negative value. Using
these values, you may then try to run the Action on the command line like this to see if it
executes properly:
UNIX:
Please note: these should be /usr/etc/webnative/actions/email/email -f "/raid/testfiles/
typed as a single line. file.eps" -k "CheckBox" -u "demo" -arg0 "sysadm@xinet.com" -
arg1 "Regarding your action" -arg2 "/usr/etc/webnative/
actions/email/settings/Demo_Email.arg02"
Windows:
C:\Progra~1\Xinet\WebNative\Bin\actions\email\email.bat -f
"G:\raid\testfiles\file.eps" -k "CheckBox" -u "demo" -arg0
"sysadm@xinet.com" -arg1 "Regarding your action" -arg2 "Pro-
gra~1\Xinet\WebNative\Bin\actions\email\Demo_Email.arg02"

For more information, debugging may be turned on in a copy of the /usr/etc/webnative/

actions/email/email script (or Progra~1\Xinet\WebNative\Bin\actions\email\
email.bat on Windows). Remember, always edit a copy of the Action script rather than
modifying the original file. After copying the script, use the instructions for enabling debug-

175
 Chapter 15: Trigger Set Customization

ging found within the script to select the desired debug level. Running the Action again, as
in the example above, should give you more information about why the Action is behaving
incorrectly. With that new information, you may be able to easily determine the cause of the
error and correct the situation. If you require more assistance, report the results to
help@xinet.com along with a description of the problem.

Background for writing Although Xinet has supplied a set of simple, common Actions beginning with WebNative
your own Actions Venture 6.0, you are not limited to using those to automate your workflow. Depending upon
your skill-set, writing Actions for use with WebNative Venture is not a difficult task. If you
are comfortable scripting or coding in any language that is executable on the server of your
choice, then writing Actions should be within your grasp.

Before you start to write an Action, have a specific workflow task in mind. Just as you must
carefully plan how to implement WebNative Venture Trigger Sets in a workflow, you must
also carefully consider what task your new Action will accomplish in that workflow. In the
ideal case, you should divide your workflow into discrete pieces that can be easily coded
individually. Then, you can link them together in the proper order when you add these
Actions to a Trigger Set.

Be certain you have a clear understanding of how Actions function. Examine the Actions
supplied with WebNative Venture carefully before you embark on writing your first custom
Action. Consider how the settings affect the outcome of the Action when it executes.

To create predictable workflows using Actions, each Action should have only one success
case. Because of the way Actions and Trigger Sets are constructed, you will have more suc-
cess writing Actions that perform simple tasks rather than one monolithic Action that per-
forms an elaborate series of tasks. Using several small Actions not only gives you
flexibility, but also the opportunity to triangulate failures and troubleshoot effectively.

When an Action exits with status 0 , WebNative Venture considers the Action to have exited
successfully. Any non-zero exit status signals to WebNative Venture that the Action failed,
and the failure case associated with that Action/Trigger rule will be executed. Examining
the supplied copy Action, note that there are two different non-zero exit statuses: -1 if the
Action is called with incorrect syntax, and -2 if there is a file-system state that disallows the
action to continue (i.e., the destination is missing). Although you may have several non-
zero exits to assist you in troubleshooting the Action in case of future failure, the Trigger
rule will only notice whether or not the exit status of the Action was non-zero and behave as
configured. Take this into account when planning your Trigger and Action workflow.

Consider also how your configuration file should be structured to provide both a useful
interface to the administrator and correct data to the Action itself. Will you require a .build-
config file to generate your .conf file? Will your user be able to type in settings, or will they
be limited to a pull-down menu?

Finally, you should evaluate any security issues that may be introduced by this Action.
Remember that all WebNative Venture Actions run with rootly powers (SYSTEM on Win-
dows), and therefore should be written carefully and deliberately to prevent accidental data
deletion or damage. Because Actions are powerful, they can also be dangerous. Verify that
any script-based Actions you write are neither readable or writable to non-root users. Fur-
ther, examine your Actions to ensure they do not use any inherently dangerous commands.

176
Background for writing your own Actions

For example, if you have a script Action that will remove a directory ($dir) using the com-
mand rm –rf $dir, and for some reason $dir is incorrectly set to /mount/point/of/raid by
error or accident, executing the Action will have a catastrophic result. Consider the most
damaging thing that could happen when running your Action, and try to prevent those pos-
sibilities inside your code.

Syntax and execution

The syntax for an Action’s execution is determined by the settings file and configuration as
described above. Also, you should review the “List of Actions” on page 150 for a discus-
sion of environment variables that you can use within your Action. You are not limited by
which language to use when writing Actions, but you are limited by what name your Action
may have. On Windows, Actions may either be named name_of_action.exe or
name_of_action.bat. On UNIX, Actions must be named without any extension.

For an example of an Action that is neither compiled nor written in csh, you may wish to
review the file /usr/etc/webnative/actions/transfer/transfer.zsh. A cousin to ksh, zsh is
included with all Mac OSX systems while ksh is not. If you are familiar with ksh, then syn-
tactically, this version should be familiar to you. Compare it to the csh version of the trans-
fer Action — /usr/etc/webnative/actions/transfer/transfer. You may prefer to write the
Action in Perl, C, or C++. So long as it is executable and runs following the execution syn-
tax described in the settings/configuration files, any programming language is acceptable
for an Action.

177
 Chapter 15: Trigger Set Customization

178
 IPTC/NAA Metadata and WebNative Venture

Chapter 16

How WebNative reads data from files

IPTC/NAA Metadata “WebNative Venture data formats — the Data Fields tab” on page 107 and several other
and WebNative Venture chapters mention WebNative Venture support for IPTC/NAA metadata. The database auto-
matically reads IPTC/NAA metadata from files and keeps track of changes made to that
metadata, writing that data into the files and into the database.

XMP Metadata and The Extensible Metadata Platform (XMP), a rich-media format developed by Adobe, pro-
WebNative Venture vides another way to embed data about a file into the file itself. In that regard, it is similar to
IPTC metadata that WebNative has supported since version 3.01. However, XMP is a more
flexible protocol with all the older IPTC fields subsumed within it. It contains:
• More preset fields for graphic and photographic arts than IPTC
• Options for creating customized fields, which can also be read and written by WebNa-
tive Venture

Entering XMP metadata

Some files enter workflows with metadata already embedded. For example, raw files from
digital cameras may provide information about file size and format, camera settings, light-
ing conditions, etc. When an operator saves a file containing this data, or, adds data by hand
using an application that creates an XMP packet, the application automatically converts this
information into XMP data. This conversion is essential for WebNative Venture, because
otherwise, the data may not be in a format that the WebNative database understands.

WebNative Venture can read XMP data embedded in files and in turn, write XMP informa-
tion into those files which support embed XMP packets. For files that cannot embed XMP
packets—for example, Microsoft Office files—it is still possible to maintain XMP informa-
tion within WebNative Venture. You can associate XMP data with a file inside the data-
base, and view that information inside a WebNative browser. When dowloading such a file,
users may request that any associated XMP data also be downloaded in a “sidecar” file.
“Downloading associated XMP information from WebNative Venture” on page 183 pro-
vides more information.

XMP and WebNative Venture

The WebNative Venture server automatically populates its database with all standardized
XMP data in files saved on WebNative Venture enabled volumes. It is also possible to make
custom XMP forms on the client side and corresponding data fields on the WebNative Ven-
ture server. WebNative Venture reads XMP data whenever:
• The dblogd(1M) daemon either updates information about a file or adds the file to the
database.
• The syncvoltodb(1M) program runs.
• The syncxmp program runs

179
 Chapter 16: How WebNative reads data from files

With more information in the database, the WebNative Venture GUI has been modified so
that administrators can view Data Field information “by sets.”

This popup allows you to

view Data Field sets.

Built-in fields, as indi-

cated by the asterisk and
lack of garbage icon, can
not be removed from the
system, although they
can always be omitted
from any Data Field set.

IntMap values are

actually integers that
have text labels
associated with some or
all of the possible
values.

FIGURE 87. Viewing data fields by sets

Predefined Data Field sets include:

• All
Displays all datafields, including locked fields and custom, user-defined fields
• Built-In
Displays only IPTC and XMP locked fields
• User
Displays only custom, user-defined fields

The WebNative Venture administrator can also create other Data Field sets. The Produc-
tion set seen in Figure 87 is one of these custom sets. (See “Establishing Data Field Sets” on
page 122 for details about creating a custom set.) Also note that Figure 87 also shows a
XMP-generated data field type, IntMap (a shortened version of Integer Map). IntMap values
are actually integers that have text labels associated with some or all of the possible values,
e.g., Urgency.

180
XMP Metadata and WebNative Venture

Once XMP data has been saved in the database, it can be searched, viewed and even edited
through a standard browser:

Custom XMP
fields viewed
through
WebNative

FIGURE 88. Gaining access to XMP metadata using WebNative

Caution: Embedded vs. associated XMP data

Data entered by operators using the File Info or Document Metadata panels in Adobe CS
applications will be embedded within files. This information will become visible to WebNa-
tive Venture users with proper access permissions as soon as a file in which metadata has
been embedded has been saved on the server.

In some scenarios, XMP fields might be created with WebNative Venture which do not have
corresponding client-side custom form fields. In such instances, Adobe CS operators will
not be able to fill in values; however, WebNative Venture users with proper access permis-
sions could see and also possibly edit values. Metadata that entered the system through such
a field would not be embedded in the file itself, even though in the database, it will be per-
manently associated with the file. Think about approval fields, as an example. In some
workflows, it might be advantageous to set them up this way; disastrous in others.

Quick start Guide for adding custom fields

WebNative Venture will automatically read standard XMP metadata from files. It can also
read custom metadata written in the XMP format. To make use of client-side custom fields in
WebNative Venture, you must also create them on the server side. Here is an overview of what is
involved:

181
 Chapter 16: How WebNative reads data from files

1. On the client side, using a text editor or third-party application, create a custom XMP
form.
2. Place the form in the appropriate folder or directory on all client systems so that it shows
up in File Info panels.
3. On the WebNative server, make sure that the database is turned on for the volume where
files will be stored, then create complimentary data fields that match those in your
client-side XMP form.
4. Check that templates and user permissions are set correctly to allow users to see and
interact with the newly-created fields as desired.
5. Test that the newly-created fields display correctly for a user who is viewing them
through a browser via WebNative.
6. Test that information entered into client-side custom forms displays as it should when
viewed through WebNative Venture.

Background: Adding custom XMP WebNative Venture fields

For custom fields in client-side XMP forms, the nativeadmin administrator must also create
corresponding fields in WebNative Venture that will hold metadata introduced from a cus-
tom form. For general information about creating data fields in WebNative Venture, refer to
“WebNative Venture data formats — the Data Fields tab” beginning on page 107. When
creating fields that correspond to the XMP namespace, keep in mind:

1. Each keyword must match its appearance in the corresponding XMP code. Case-
sensitivity withstanding, they must match exactly.
2. WebNative Venture data field names can not contain blank spaces. This is a limitation
from XMP specifications; not from WebNative Venture. If the WebNative Venture fields
contain blank spaces, they will not be populated with XMP data.
3. The data field type, e.g., pop-up, boolean, etc., must be the same in WebNative Venture
as is in the custom form.
4. XMP conventions maintain that, internally, data field names must follow the conventions
mentioned in items 1. and 2., and in addition, be prepended by a namespace. Internally,
WebNative Venture checks whether or not you have preprended fields you define with a
namespace and if you haven’t, prepends xwnv. This means that you could, for example,
name a field Approval, yet internally, the database would use xwnv:Approval.
WebNative also offers some other alternatives if you want to display labels for users that
violate XMP regulations. For example, perhaps you want them to see the phrase
Approval Status, which contains a forbidden blank space.
The easiest work-around involves creating a new local.js file which contains your
preferred label. Alternatively, if you wish to display a different label for one or more
users, you can create a user.js file. Here’s the procedure for a creating the appropriate
local.js file. The same thing could be done for any user in a user.js file:
a. Create a local.js file. On UNIX systems, the file should reside in
/var/adm/webnative. On Windows systems, it should reside in
C:\Program Files\Xinet\WebNative\Admin\.

182
XMP Metadata and WebNative Venture

b. Using a text editor, add the following lines in the file:

<SCRIPT>
lang.keywordIDNUMBER = "New Description";
</SCRIPT>
(where IDNUMBER is the keyword’s WebNative Venture ID number and New
Description is the label you want end users to see.)

After just creating a new keyword field, the easiest way to find out its ID number is to
select the newly-created field using the pop-up list under the Edit Data Fields
subtab. You’ll find the ID number there, as shown in the following example:

The lang.keyword ID number.

FIGURE 89. Locating the language ID number for a field

For the example shown above, we’d add the following to the file:

lang.keyword193 = "Approval Status";

Downloading associated XMP information from WebNative Venture

Any XMP information that can be viewed on the web can also be downloaded. By default,
when a remote WebNative user downloads a file, that file will contain any XMP information
embedded in the file, but will not contain XMP data that is merely associated with the file in
the database.

183
 Chapter 16: How WebNative reads data from files

Some workflows may be interested in exporting all XMP data associated with a file. To that
end, the WebNative Shopping Basket includes an option that allows a user to export all
XMP data. Figure 90 shows the interface:

FIGURE 90. Exporting associated and embedded XMP metadata

When a user marks the XMP Export option Yes, the file itself and an additional file contain-
ing all the XMP data will download. For example, when downloading 192547-b.tiff, Web-
Native downloads 192537-b.tiff and 192537-b.xmp:

FIGURE 91. Downloading an image with its associated XMP metadata

More generally stated, downloading the high-resolution version of a file from the Basket
called myfile.extension would result in two files on the desktop:
myfile.extension and myfile.xmp

Downloading the low-resolution version of myfile.extension would result in only a

low-resolution copy of myfile.extension. XMP data will not be included.

Understanding data field names

Labels for fields in the WebNative Venture database may not always have the exact labels
operators see in Adobe CS dialogs. This has to do with Adobe’s rules for aliases between
namespaces.

Looking inside an Adobe CS File Info panel, you’ll notice a list of metadata “namespaces.”
They include (as of this publication date) Description, Camera Data 1, Camera Data 2, Cate-

184
 XMP Metadata and WebNative Venture

gories, History, IPTC Contact, IPTC Content, IPTC Image, IPTC Status, Adobe Stock Pho-
tos, Origin, Dublin Core Properties, XMP Core Properties, XMPMedia Management
Properties, PDF Properties, PNG Properties, and TIFF Properties.

When an operator saves a file, the Adobe application actually rewrites a number of standard
metadata formats into XMP. Often times, then, the same data will be associated with a file
more than once. For example, an operator may enter data in IPTC-specified fields and it will
appear again, encoded in XMP format. XMP specifications provide aliases for many such
fields, sometimes affixing a different XMP label for a given metadata field than the label
affixed to that field in its original namespace.

For maximum backward compatibility, WebNative Venture is preserving the old name used
for IPTC-NAA fields in Photoshop 7 and lower. Table 4 shows possible mappings of Photo-
shop 8 and higher to the old-style IPTC fields used in WebNative Venture.

TABLE 4. WebNative Venture metadata name mapping

Photoshop Photoshop
7 & lower 8 & higher XMP Dublin
IPTC File Info File Info PDF TIFF XMP Core Rights Core
window window (pdf:) (tiff:) (xmp:) Manager (dc:)
Object Title Document Title Title title
Name Title
ByLine Author Author Author Artist Author creator
Caption Caption Description Subject ImageDe- Description description
scription
Caption Caption Description
Writer Writer Writer
Keywords Keywords Keywords Keywords subject
Copyright Marked
Status
Copyright Copyright Copyright rights
Notice
Copyright WebState-
Info URL ment
Created Date DateCreated Date Creation CreateDate
Created Date
City City City
Province/ State State/
State Province
Country Country Country
Credit Credit Credit
Source Source Source
Headline Headline Headline
Special Instructions Instructions
Instructions
Trans Refer- Transmis- Transmis-
ence sionRefer- sion Refer-
ence ence
Urgency Urgency Urgency

185
 Chapter 16: How WebNative reads data from files

TABLE 4. WebNative Venture metadata name mapping

Photoshop Photoshop
7 & lower 8 & higher XMP Dublin
IPTC File Info File Info PDF TIFF XMP Core Rights Core
window window (pdf:) (tiff:) (xmp:) Manager (dc:)
Category Category Category
Supplemen- Supplemen- Supplemen-
tal Catego- talCatego- tal Catego-
ries ries ries

For more information, about the aliases specified in XMP rules and adopted by WebNative
Venture, please refer to Adobe’s documentation, XMP – Extensible Metadata Platform,
which you can download from:
http://partners.adobe.com/asn/tech/xmp/download.jsp

Another good source of information:

http://www.adobe.com/products/xmp/in-depth.html.

Background: How Let’s start with an example file, gears.tiff, that has the following fields, assigned with the
Metadata is stored in the following values:
WebNative Venture
database

TABLE 5. Example: metadata fields and values within gears.tiff

Name Value Pop-up values

a_text one
a_date 1/1/006
an_integer 1
a_float 1.0
a_boolean true (true/false)
a_text_popup a_text_popup (a_text_pop/another_test_popup)
an_integer_popup 10 (5/10/15)

The gears.tiff file’s fileid is 374. (You can determine this by looking in its source when
browsing or when displaying information about the file using WebNative’s imageinfo pro-
gram.)

Each field created has a record in the keyword table. They are distinguished by keywordids. You
can find the keywordid for each record in at least two ways:

1. If you were to click on the file’s WebNative Image Info icon and then look at its source
code, you would find:
var keywords = new Array();
keywords[0] = new
keyworditem(62,0,1,"a_boolean",'',100,0,20,1,0,0,'True/
False',0,0,0,0,0);

186
Background: How Metadata is stored in the WebNative Venture database

keywords[1] = new
keyworditem(59,1,1,"a_date",'',12,14,14,1,0,0,'%c/%e/
%y',0,0,0,0,0);
keywords[2] = new
keyworditem(61,2,1,"a_float",'',104,12,14,1,2,0,'',0,0,0,0,0);
keywords[3] = new
keyworditem(60,3,1,"a_integer",'',3,0,14,1,0,0,'',0,0,0,0,0);
keywords[4] = new
keyworditem(58,4,1,"a_text",'',253,64,14,1,0,0,'',0,0,0,0,0);
keywords[5] = new
keyworditem(63,5,1,"a_text_popup",'',253,64,14,1,0,0,'',0,0,0,0,0
);
keywords[6] = new
keyworditem(64,6,1,"a_integer_popup",'',2,0,14,1,0,0,'',0,0,0,0,0
);
The first item in the parentheses is the keywordid number for the field.
The fourth item in the parentheses is the name of the keyword.
2. If you were to provide the mysql client with:
select keywordid, name from keyword;
the results should include:
58 | a_text
59 | a_date
60 | an_integer
61 | a_float
62 | a_boolean
63 | a_text_popup
64 | an_integer_popup
The keyword table also specifies the type of values that it can hold, its appearance, etc.
See Xinet TechNote 137: Documentation for WebNative Venture MySQL data tables for
full details.

Every field in the keyword table has a corresponding field in the (unfortunately named)
keyword1 table. This is where the current value of a field is stored. In particular, the keywor-
did number has a corresponding FieldXX field in keyword1, where XX is the keywordid
number. For instance, the keyword with keywordid number 58 (a_text) has an associated
field in keyword1 called Field62.

Any file that has metadata applied to it has an entry in the keyword1 table. The primary field
in this table is the fileid. Note that only files with metadata applied to them are in this table.
For every fileid in this table, a value can optionally be applied to any of the Field fields.

In the above example, fileid 374 has values in 7 fields within keyword1.

Here is what they look like in MySQL:

mysql> select Field58, Field59, Field60, Field61, Field62, Field63,
Field64 from keyword1 where fileid = 374;
+---------+---------------------+---------+---------+---------+-----------------+---------+
| Field58 | Field59 | Field60 | Field61 | Field62 |
Field63 | Field64 |
+---------+---------------------+---------+---------+---------+-----------------+---------+
| one | 2001-01-01 00:00:00 | 1 | 1.00 | 1 |
one_popup_value | 10 |
+---------+---------------------+---------+---------+---------+-----------------+---------+
1 row in set (0.00 sec)

187
 Chapter 16: How WebNative reads data from files

If the field is a popup, the applied value shows up in the keyword1 table, but the popup val-
ues themselves are stored in one of many value tables. Popup values for text fields are
stored in value253, while integer values are stored in value2. The number refers to the data
type of the values stored. (Again, see Xinet Technote 137 for full details.)

In the above example, the popup values (5/10/15) for the an_integer_popup keyword are
stored in the value2 table. When a value of 10 is assigned to the gears.tiff file, the value of
10 is stored in the keyword1 table.

188
 Introduction

Chapter 17

Importing data into WebNative Venture

Introduction This chapter is for those who already have some experience working with databases. If you
do not, you should probably defer the task to someone who has more experience. Success-
ful WebNative Venture importation is usually an iterative process through which you deter-
mine which arguments the WebNative Venture import program needs for your particular
data migration. Because every set of exported data will have its own characteristics, Xinet
can not provide exact step-by-step procedures that will work without modification. How-
ever, in this chapter, we hope to provide a good notion of how the process works.

The WebNative Venture import program is designed to move file names, file information,
metadata, and previews from a text file into a Venture database. The program requires a text
file with fields delimited by some character (a comma, a tab, etc.). Most databases can
export data into a text file in that format.

From the start, it’s important to distinguish between two cases:

• When data files will be moved to the WebNative Venture server
If you decide to move your data files onto your WebNative Venture server, WebNative
Venture can automatically read in existing file names, file information, and previews.
This information will not need to be included in an exported text file. The process of
gathering this information, however, will take WebNative Venture a bit of time. Once
done, the import program can attach metadata to the appropriate records in the WebNa-
tive Venture database. For this to work, the import program must know the originating
path of the files, as well as the new path to the files on the server.
If you were to move data files to the new system and archive them immediately, i.e.
before running the WebNative Venture import program, the import program would still
be able to successfully attach metadata to the archived files.
• When data files will not be moved to the WebNative Venture server
When data files are not moved onto the WebNative Venture server, WebNative Venture
can not read in file names, file information, nor previews. New records of this informa-
tion, therefore, must be made in the database because the files are not on the server. The
exported information must include everything you want to access in WebNative: i.e. file-
names, file information, metadata, and previews. Once the information has been suc-
cessfully imported, the result will be a collection of “virtual” files—metadata will be
stored, and potentially, if you set it up this way, file previews too; but, actual images will be
absent. These files become Archives in a tape called DUMMY.

The import command Following are two examples of imports, with the use of flags explained.

Case one: files are moved onto new server before running import

In this example, we copy a folder called Images from one server to another. On the original
server, Images was in /raid/2002/. On the new server, it will be on
/Volumes/Imports/OSX/CustomerData. A database tracked the location of files and meta-

189
 Chapter 17: Importing data into WebNative Venture

data on the original server. The goal, now, is to copy the file to the new server and import the
metadata into WebNative Venture, associating it with the correct files:

1. Copy your data onto the WebNative Venture server.

2. Create an “export” file from your original sample data, i.e., a delimited text file made
from the old database. Each file needs a “record” which should contain the path to the
file, as well as the metadata associated with the file. All other info will be read in
automatically by WebNative Venture.
Here are three example comma-delimited records from an export file:
start
/Raid/2002/Images,textshort1,tttteeeeeexxxxxxtttttloooonnngggg1,
3/15/2005,2005/3/15 11:11:11 AM,25,251,250001,25.52,1,
Bylinetest1,25
/Raid/2002/Images/Dalim Demo,textshort2,tttteeeeeexxxxxxttttt-
loooonnngggg2,3/15/2005,2005/3/15 11:11:11
AM,25,252,250002,25.52,1,Bylinetest2,25
/Raid/2002/Images/Dalim Demo/4A.dct,textshort3,tttteeeeee-
xxxxxxtttttloooonnngggg3,3/15/2005,2005/3/15 11:11:11
AM,25,253,250003,25.52,1,Bylinetest3,25

The export file has the path to the files and all associated metadata. It is usually impor-
tant that the export file provides paths to the files as they were on the old server. Typi-
cally, the imported files will have the same or a similar folder structure. The metadata in
the export file will be matched up with fields created in WebNative Venture’s database.
3. Create metadata fileds in WebNative Venture. Here is an example of fields that match
the data in the export file:
Name Type
textshort (16 chars)
textlong (60 chars)
date4 (the 4th date listed in nativeadmin’s view)
date18 (the 18th)
int1 (1 byte integer)
int2 (2 byte integer)
int4 (4 byte integer)
float (float)
boolean (boolean)
Byline (IPTC text)
Urgency (IPTC tiny int)
4. Construct your import command. (On UNIX systems, the import program lives in /usr/
etc/venture/bin; on Windows systems, it’s in C:\Program Files\Xinet\Venture\bin).
TIP:You may want to make a script that contains your test import command. Typically
one has to run the command a few times to work out syntax errors. Putting the command
in a file and running the file as a script allows you to edit the command more easily than
retyping everything at the command-line prompt.
– Begin the file with #!/bin/csh -f.
– Then, write the import command
– Set the file’s permissions so that the file is executable. Let’s say the file were named
cmd:
# chmod cmd 777

190
The import command

– Run cmd, directing output to a log file so you can see any debugging messages:
./cmd >& log &
An import command to handle the example export file above would look like this:
/usr/etc/venture/bin/import “export.txt” -onlyexisting -s2c
-r0A -g73746172740a -ipath_to_file -ttextshort -ttextlong
“-ddate4’MM/DD/YYYY’:def=09/20/1972” “-ddate18’YYYY/MM/DD
hh:mm:ss AA’:def=1972/09/20 11:11:11 PM” -uint1 -uint2 -uint4
-ffloat -uboolean -tByline -uUrgency -b”/Volumes/Imports/OSX/
CustomerData%10c1%”
where export.txt is the name of the export file.
Here’s the same command, separated flag-by-flag, for easier inspection:
/usr/etc/venture/bin/import “export.txt”
-onlyexisting
-s2c
-r0A
-g73746172740a
-ipath_to_file
-ttextshort
-ttextlong
“-ddate4’MM/DD/YYYY’:def=09/20/1972”
“-ddate18’YYYY/MM/DD hh:mm:ss AA’:def=1972/09/20 11:11:11 PM”
-uint1
-uint2
-uint4
-ffloat
-uboolean
-tByline
-uUrgency
-b”/Volumes/Imports/OSX/CustomerData%10c1%”
In an iterative process, adjust arguments to the import command. Here is what each
argument in our example does:
Argument Explanation
“export.txt” In our example, the name of the file containing the exported data-
base. In real life, you can name the file anything you choose.
-onlyexisting The import will only match files that have records in the database
already. If the file can't be found, no new (or “virtual”) entry is
made.
Also see the -onlynew flag, described in Case 2.
If neither flag is used, the import program will match with existing
records if they can be found, and make new records if they cannot
be found.
-s2c Hex value of the separator between each column in a record. In this
case, a comma is the separator.

On UNIX systems, the command od -x will provide this value for

you. See od(1) for details. On Windows systems, use a Hex editor
to determine the value.
-r0A The hex value of the separator between each record. Typically
that’s a Return, whose hex representation is 0A.

191
 Chapter 17: Importing data into WebNative Venture

-g73746172740a The last string (in hex) before the start of the data. In the export.txt
file, the string is start plus a Return (thus the final 0a).
You may alternatively use a -o flag, which tells, in hexadecimal
bytes, how much of the file to skip.

The following flags deal with the actual data in the export file. The first argument deals
with the first column, the second one the second column, and so on.

-ipath_to_file The -i argument means ignore the first column, i.e., the path in our
example. While it may seem odd to ignore the path, the path is
really dealt with by the -b argument, as explained below. The -i
argument can be used to ignore any field. The string following the -
i (path_to_file in this case) is purely optional. It’s a good way, how-
ever, to note what is being skipped.
-ttextshort The -t argument identifies a text-field name, as it exists in the Web-
Native Venture database. In this example the field’s name is text-
short.
-ttextlong Another text field (also previously established in WebNative Ven-
ture) called textlong.
-ddate4’MM/DD/YYYY’:def=09/20/1972
Delineates a date field called date4 that uses the format in the
quotes. The def= value provides the default to be used when the
exported data doesn’t contain a value. A default is optional.
-ddate18’YYYY/MM/DD hh:mm:ss AA’:def=1972/09/20 11:11:11 PM
Another date field. The format of all dates follows these rules: Y =
year M = month D = day h = hour m = minute
s = second AA=AM or PM.
As an example, consider the date December 1st, 2004. For a format
like 12/01/2004, the date argument should be MM/DD/YYYY. For a
format like 12/01/04, the date argument should be MM/DD/YY. For
a format like 04/12/01, the date argument should be YY/MM/DD.
The format of the date in the export file does not have to match the
format of the date field in WebNative Venture. Upon import, the
dates are converted to UNIX time. The display format of the date
field in WebNative Venture determines what the date will look like
when actually seen in WebNative.
-uint1 Integer field
-uint2 Integer field
-uint4 Integer field
-ffloat Float field
-uboolean Boolean field
-tByline A text field that happens to be an IPTC field.
-uUrgency An integer field that happens to be an IPTC field
-b”/Volumes/Imports/OSX/CustomerData%10c1%”

192
The import command

The goal of the -b argument is to construct the paths to all the files
being imported. Without knowing the path to the file, the import
command will not attach metadata.

Part of the argument will be a constant. All the files will be within a
certain area on the server, say Volumes/Imports/OSX/Customer-
Data. If that part of the path will be common to all files, it should
be the first part of the argument.

Another part of the argument will vary from file to file. Files will be
in different directories and have different names. The location and
names of the files are in the export file in fields, and the import
command needs to find them as it runs through each record. To find
this information, some variables are used.

The two % signs surround a variable. A number within those signs

stands for a field number in the export file. 1 stands for the 1st field,
2 for the second field, and so on. Thus, %5% refers to the fifth field,
and the value of that field will be substituted in place of the %5% If
field 5 has the path to the file and its name, this would be the field
number to use.

NOTE FOR WINDOWS

When using the import command interactively, i.e., on the com-
mand line, use only one percent sign on each side of the field num-
ber, e.g., %5%. When scripting a .bat file, however, use double
percent signs on each side of the field, e.g., %%5%%.

A number followed by a c means to “clear” that number of charac-

ters from the string with which the field number was associated.
For example, %10c5% means to substitute in the value of the fifth
field, but remove the first ten characters of the string. If the fifth
field's value is /raid/data/Customers/, then %10c5% would evalu-
ate to /Customers/.

An m means to convert the path format of the string from the Mac-
intosh style to the UNIX style. Macintoshes use colons to separate
folders while UNIX uses forward slashes. The m converts to the
UNIX style. An example of using it in conjunction with the clear
flag would be: %10cm5%.

There is no need to convert from Windows style paths (back-

slashes) to UNIX. These are converted automatically.

Multiple fields can be specified within the two % signs. For

instance, %5%%6%%7% is a valid argument. This can be useful if
the path to the file is not in one field but split into several fields. The
path can be “constructed” in this manner.

Now let's look at our example.

193
 Chapter 17: Importing data into WebNative Venture

Remember that we had a folder called Images which we moved to

the new server. We placed it in /Volumes/Imports/OSX/Customer-
Data, the new home for Images. WebNative Venture copied all the
file information into its database at the time the files were moved
onto the server. The old server had the images in /Raid/2002/
Images. An example record from the export file would show:

/Raid/2002/Images/Dalim Demo/4A.dct

Each record in the export has a path similar to that. On the new
server, that file’s location is:

/Volumes/Imports/OSX/CustomerData/Images/Dalim Demo/4A.dct

The -b argument begins with the part of the path that will be com-
mon to all the imported files:

/Volumes/Imports/OSX/CustomerData/

The second part of the location, Images/Dalim Demo/4A.dct, is

specified by %10c1%. Here, the final 1 is a variable representing
the first field in the export file. For this sample record, the value is /
Raid/2002/Images/Dalim Demo/4A.dct. The 10c tells the import
program to skip the first 10 characters in that string. So /Raid/2002
is stripped out, leaving
/Images/Dalim Demo/4A.dct. The program places this string after /
Volumes/Imports/OSX/CustomerData, giving us the grand result:

/Volumes/Imports/OSX/CustomerData/Images/Dalim Demo/4A.dct

Now that the file is “matched,” its metadata can also be read in. The
same process happens for each record in the export file.
5. Run the import command.

Make sure that users aren’t working on the files at the time of the import. The dblogd
daemon does not need to be stopped.

Case two: files are not moved onto new server

In this case, the images are not actually moved to the server. Instead, they will appear as
archived files with the nearline tag in WebNative. Users will be able to see the file names,
characteristics, previews, and metadata. Let’s say that the old server had the Images direc-
tory located at /Volumes/Quark-Test/OPI Testing. On the new server, we want the “archived
files” to appear under /raid/CustomerData/Archives. Here is how to proceed:

194
 The import command

1. Create an export file—which, this time may have more than metadata in it. Here are
three comma-delimited records from an example file:
/Volumes/Quark-Test/OPI Testing/Images,8001,7001,6001,11/11/11
11:11:11 AM,22/22/22 22:22:22 AM,33/33/33 33:33:33 AM,..CT,8BIM,
textshort1tttteeeeeexxxxxxtttttloooonnngggg1,03/15/2005,2005/03/
15 11:11:11 AM,25,251,250001,25.52,1,Bylinetest1,25
/Volumes/Quark-Test/OPI Testing/Images/alias
EPS,8002,7002,6002,11/11/11 11:11:11 AM,22/22/22 22:22:22 AM,33/
33/33 33:33:33 AM,..CT,8BIM,textshort2,tttteeeeeexxxxxxttttt-
loooonnngggg2,03/15/2005,2005/03/15 11:11:11
AM,25,252,250002,25.52,1,Bylinetest2,25
/Volumes/Quark-Test/OPI Testing/Images/alias EPS/cmykepsbinary-
withpath,8003,7003,6003,11/11/11 11:11:11 AM,22/22/22 22:22:22
AM,33/33/33 33:33:33 AM,..CT,8BIM,textshort3,tttteeeeee-
xxxxxxtttttloooonnngggg3,03/15/2005,2005/03/15 11:11:11
AM,25,253,250003,25.52,1,Bylinetest3,25
2. Create metadata fields in WebNative Venture. For this example, we’ll use the same
fields listed in Case 1.
3. Construct the import program, using appropriate arguments. The arguments are largely
the same as in Case 1, but there are new flags you might want to use.
For this second example, we use:
Argument Explanation
-z (file size)
-w (image width)
-h (image height)
-T (file mac type)
-C (file mac creator)
-onlynew If this flag is used, the import program will only match files that did not have records in the
database. This will make all new (or “virtual”) records.
Also see the onlyexisting flag, described in Case 1.
If neither flag is used, the import program will match with existing
records if they can be found, and make new records if they cannot be
found.
The next three dates use this format: -m <date definition string>’[:def=<default value>]
MM/DD/YY hh:mm:ss AA.They (file modified date)
make additions to the Modify Date
(-m), Create Date (-c), and Backup -c <date definition string>’[:def=<default value>]
Date (-a) fields in the file table.
(file creation date)
-a <date definition string>’[:def=<default value>]
(file ARCHIVE date)
Here’s a sample import command, where the import file is called export.txt:
/usr/etc/venture/bin/import “export.txt” -onlynew -s2c -r0A
-g73746172740a -ipath -zFileSize -wWidth -hHeight -mModifyDate
-cCreateDate -aArchiveDate -TType -CCreator -ttextshort -ttext-
long “-ddate4’MM/YY/YYYY’:def=09/20/1972” “-ddate18’YYYY/MM/DD
hh:mm:ss AA’:def=1972/09/20 11:11:11 PM” -uint1 -uint2 -uint4
-ffloat -uboolean -tByline -uUrgency -b”/raid/CustomerData/
Archives%31cl%”
Here’s the same command, separated flag-by-flag, for easier inspection:

195
 Chapter 17: Importing data into WebNative Venture

/usr/etc/venture/bin/import “export.txt”
-onlynew
-s2c
-r0A
-g73746172740a
-ipath
-zFileSize
-wWidth
-hHeight
-mModifyDate
-cCreateDate
-aArchiveDate
-TType
-CCreator
-ttextshort
-ttextlong
“-ddate4’MM/YY/YYYY’:def=09/20/1972”
“-ddate18’YYYY/MM/DD hh:mm:ss AA’:def=1972/09/20 11:11:11 PM”
-uint1
-uint2
-uint4
-ffloat
-uboolean
-tByline
-uUrgency
-b”/raid/CustomerData/Archives%31cl%”
4. Run the import command.
When the command has been run, the files will appear as “Near Line” files in WebNative.
In the database, each file will have an entry in the archivefile table. There will also be a
new archivemedia entry with a medianame of IMPORTED. The archive file entries will
use the mediaid for the IMPORTED entry.
An archive media other than IMPORTED can be specified with the
-mMediaName flag. The only criteria is that the archivemedia record for the MediaName
already exist in WebNative Venture.
The archive state (whether a piece of media is online, nearline, or offline) can be
changed with the venturelog utility, or by altering the archivemedia table in the mysql
console.

Additional notes
• There is a -preflight flag that will parse the export file but not take any action. Xinet
highly recommends using this flag before doing a real import.
• In any case, it is fine to rerun the import command. Existing metadata values will be
overwritten.

196
The import command

• There is a -D flag for debugging, which is useful if the import command fails to find
metadata fields or files. If a file can’t be found, the debugging file will show something
like:
File /Volumes/California/Imports/OSX/CustomerData/Images/
file_list is not in the database, skipping record.
• There is an -ignoredataerrors that will proceed with the import regardless of errors.
• There is an -ignoremissingfields that will also proceed with the import regardless of
errors.
• If you run import without any arguments, you’ll get a usage summary.
• Metadata fields can be given default values. These values will be inserted if a field in the
export file has no value. The syntax is the same for integer, float, text, and date fields:

-u<name>[:def=<default value>]
For example, here is an integer field called Days_To_Complete with a default value of
“30”: -uDays_To_Complete:def=30.
• The import command expects the language character set of the data being imported to
be the same character set used by the WebNative Venture database. By default, WebNa-
tive Venture uses Latin1, which is sufficient for most European language strings. If the
export file is also in the Latin1 character set, then the import command does not need to
do anything special to handle the special characters. Likewise, a database using SJIS
will have no trouble importing an export made in SJIS. If a field in the export file is in a
different character set (SJIS, BIG5, MAC, UTF8), then the import command should
note, per field, what set was used while making the export. For example, if the text field
called person has values in the export file in UTF8, and the database does not use UTF8,
then the import argument should read:
-tperson:char=utf8
This needs to be done for each data field. Character-set arguments for
the WebNative Venture’s import command include:
latin1 (Standard Roman character set; common on PCs)
utf8 (Unicode; OS X native encoding)
sjis (Shift-JIS Japanese encoding)
mac (OS 9 native Macintosh Roman encoding)
Note that the file on the server will be encoded using Xinet's format. This is not the same
encoding used on the Mac (which will be Latin1, MAC, UTF8, etc). For special charac-
ters, that means that the file name will not look the same if the UNIX name and the Mac
name are compared. WebNative Venture adds both names to the database record, but
when importing it matches against the
Macintosh name.
• The -A flag is used to import archive information about files. It is useful for migrations
from one server to another.Typically, you would export this information from a Webna-
tive server into a file using the export command. The export command writes all the
required information in the required format. If that data needs to be preservered on the
new server, simply adding the -A flag to the import command will be enough.
Alternately, one can add archive information by hand to the file you plan to use with the
import command (i.e., the “exported” file).

197
 Chapter 17: Importing data into WebNative Venture

You should add information in two places:

1. Within the comments of the exported file, add all of the tape and status
information.
There should be one entry for each tape:
#
# Venture Tape Definition
# <MediaID><tab><TapeName><tab><online 0/1><tab><nearline 0/1><tab><offline 0/1><tab>
# <MediaID><tab><TapeName><tab><online 0/1><tab><nearline 0/1><tab><offline 0/1><tab>

# <MediaID><tab><TapeName><tab><online 0/1><tab><nearline 0/1><tab><offline

where:
online, nearline, and offline require values of either 0 or 1.
mediaid requires a number
tapename requires a name
the delimiter must be a <tab>
there must be a final <tab>
2. At the end of each record, list archive information .
This is a single field, separated from other fields by whatever delimiter has been
specified. (In our example below, we will assume that is a <tab>.)
Within this field, the information is split up by commas:
<archive date in unix time>, <media id>, <archive number>,
<size>, <thumbnail offset>, <thumbnail size>, 0x00<tab>

The final <tab> in this example marks the end of this field. The final 0x00 is
necessary at the end of the field.
A single file may have been archived more than once. After a “;” the archive
information can be repeated for the file as many times as necessary:
<archive date in unix time>, <media id>, <archive number>,
<size>, <thumbnail offset>, <thumbnail size>, 0x00;<archive
date in unix time>, <media id>, <archive number>, <size>,
<thumbnail offset>, <thumbnail size>, 0x00...<tab>

Importing from a Cumulus 4 and Cumuls 5 databases can export data to text files, which can then be imported
Cumulus data base to WebNative Venture. The import program has special flags made for Cumulus exports.

The elements we are concerned with are:

• File information (type, creator, file size, create date, etc.)
• Previews
• Metadata
• Full path to the file

These elements can be exported in different ways, depending on the version of Cumulus
used. WebNative Venture currently support exports from Cumulus 4 and 5.

198
Importing from a Cumulus data base

File information

File information may be in distinct fields, or it may be kept in one “asset reference field”
that is in a binary format. When the information is in distinct fields, you can write an import
command that puts those values into the new file table directly. For example, the -T and -C
flags put the appropriate values in the type and creator columns in the file table. If the infor-
mation is in a single “asset reference” field, then the -n flag needs to be part of the import
command. This option will extract all file information from the asset field and put it into the
appropriate fields in the new file table.

Previews

Previews for the Cumulus files are in a proprietary hex format. Using a -e option in the
import command will extract the preview, convert it to binary, and place it in the appropri-
ate tables within WebNative Venture. Previews can become small previews or large pre-
views in WebNative Venture or even FPOs. For example, the flag
-esmallweb would put the preview for each file into the smallwebdata table.

Metadata

A Cumulus export file may or may not provide metadata in distinct fields. If distinct fields
are used, the data can be imported as normal, using the regular flags for matching with
existing metadata fields in WebNative Venture.

With Cumulus 4, however, all exported metadata is commonly placed at the end of a record,
right after the image preview. In such cases, Cumulus 4 does not make distinct fields for
each metadata field. The values are listed one after another. As a result, it is impossible to
direct values to particular metadata fields in WebNative Venture. However, it is possible to
“merge” all the values for one record into a single WebNative Venture field. Typically, this
will be something like a Notes field. The -M flag does the “merging.” This -M flag must be
the last flag in the import command. The Notes field (the name is just an example) must also
already exist in WebNative Venture and should be large enough to accommodate all the
data. Note that metadata found with -M follows the same character set translation rules as
with other metadata fields. For an export saved in the “Mac” characterset, the flag to use
would be -MNotes: charset=mac.

In Cumulus 5, exported metatdata is generally in distinct fields, so there is no need to use

the -M flag.

Path

Full path information is usually part of the asset reference field. If you use the -n flag, the
import program will be aware that the path is part of this field. You can use the -b flag to
construct the path, using the field number to stand for the full path to the file. For example,
if the field with the asset references were field 15, the argument would look like: -
b”%15%”. The import program would extract the full path from the asset reference field and
put in place of the “%15%”.

199
 Chapter 17: Importing data into WebNative Venture

In Cumulus 5, the path to a file and the filename are usually in separate fields. An example
might be:

Field 13 the volume name

Field 15 the path name (could require a m to specify format of path)

Field 14 the file name

So, as an example, the path might be referred to as:

-b”%15%/%14%”

Here is an excerpt from a sample export file made from Cumulus 4: Two chunks of binary
data (fields 21 and 22) are truncated. The first is the asset reference; the preview is second.

Copyright 1992, Canto GmbH Berlin, Cumulus 1.0 Export

EPSF,8BIM,7/26/01 9:28:26 PM,7/26/01 9:28:27
PM,200699,15714,2,302,298,0.55554,0.70833,0,0,8/16/01 10:08:19 AM,8/
16/01 10:10:43 AM,63435C1.s-22.8%Max ButtonHi.eps,Status,AssetMan-
ager,Adobe Photoshop Version
6.0.1,43754170020A000200000F462E657073,0100803247634509823401000000
0100,60000-69999:63435,MOVIES:H:How the Grinch Stole Christmas

import "cumulus4.export" -s2c -r0D -g4578706F7274 -TType -CCreator

"-cCreateDate'MM/DD/YY hh:mm:ss AA'" "-mModifyDate'MM/DD/YY hh:mm:ss
AA'" -zFileSize -iResForkSize -iColorSpace -iHRes -iVRes -iHdpi -
iVdpi -iUnknown -iUnknown "-aArchivedDate'MM/DD/YY hh:mm:ss AA'" "-
dRecordModifyDate'MM/DD/YY hh:mm:ss AA':def=01/01/2000 01:00:00" -
iFilename -iStatus -iUser -iOpenerApp -nAssetReference -ePreview -
MNotes -b"/raid/CustomerData/%m20%"

-g4578706F7274 The data starts after the string Export.

-nAssetReference This will get the full path and make it available to the import pro-
gram as "%20%" (the 20th field)

-ePreview This will read in the preview exported in the file.

-MNotes Will merge together all the fields starting with the 22nd field.

-b Will use the path to the file extracted from the AssetReference field.
The m converts Macintosh format paths to the UNIX format.

200
 Chapter 18

Using the export function in WebNative Venture

WebNative® Venture includes an export executable which will allow you to create either flat
files or XMP output from your WebNative Venture assets. This provides portability of your
WebNative Venture data for use in applications that read these formats.

There are two kinds of files that can be exported from WebNative Venture using the export
command: flat files and XMP files. Flat files are easily imported by a variety of programs,
including spreadsheet applications and other databases. XMP is an XML-based standard
written by Adobe and used for data storage in their more recent applications, including the
Adobe Creative Suite. To learn more about XMP, visit Adobe’s XMP website at http://
www.adobe.com/products/xmp/main.htm/.

Both flat files and XMP files may be exported for single documents, folders of documents,
or the entire database. When the export command is run for a folder, export creates a single
output file containing all metadata for all files inside that folder. When the export command
is run for a single file, only information about that file will be exported.

For the most up-to-date information about export command options, rely on its online
usuage summary. (Type the command without providing any arguments.)

Note: For standardization, the export command exports all text in utf8 (Unicode) on both
UNIX and Windows servers.

To export a flat file, the syntax is:

Please note: this should be /usr/etc/venture/bin/export [/path/to/output/file] [/path/to/
typed as a single line. file/or/directory]

By default, the flat files use a tab field separator.

A sample flat-file export for a single file looks like this:

# Export File generated by Xinet WebNative Venture.
#
# Copyright (c) 2003 by Xinet Inc. All Rights Reserved.
#
# To import back into Venture, run:
#
# import <filename> -s09 -r0A -g232073746172743A0A "-iUnix-
PathName" "-iMacName" -TType -CCreator "-mModification
Date'YYYY-MM-DD hh:mm:ss'" "-cCreation Date'YYYY-MM-DD
hh:mm:ss'" "-b%1%"
#
# start:
/chilly/files/myfile.jpg myfile.jpg JPEG 8BIM
2004-03-26 21:52:19 2004-03-26 21:52:21 myfile.jpg?8
<tab> <tab> <tab> <tab> <tab> xinet\nful-
lpress\nwebnative\n <tab> <tab> <tab> <tab>

201
 Chapter 18: Using the export function in WebNative Venture

<tab> <tab> <tab> <tab> <tab> <tab>

<tab> Xinet, Inc.8 <tab> <tab> <tab> <tab>
<tab> <tab> <tab> <tab> <tab> <tab> This
is myfile.jpg. It is a picture. <tab> Xinet, Inc.8
<tab> <tab> <tab> <tab> <tab> <tab>
<tab> <tab> <tab> <tab> <tab> <tab>
<tab> <tab> <tab> <tab> <tab> <tab>
<tab> <tab> <tab> <tab> <tab> <tab>
<tab> <tab> <tab> <tab> 1<tab> 0<tab>
0<tab> 0<tab> 0<tab> 0<tab> 0<tab> 0<tab>
0<tab> 0<tab> 0<tab> 0<tab> 0<tab> 0<tab>
0<tab> 0<tab> 0<tab> 0<tab> 0<tab> 0<tab>
0<tab> 0<tab> 0<tab> 0<tab> 0<tab>

Each of the fields in the database is represented in the flat file export, even if that field does
not have a value set for this file. These flat files are not very easy for a person to read, but
they are easily imported into a variety of other programs.

To export an XMP file from WebNative Venture, the syntax is:

/usr/etc/venture/bin/export [/path/to/output/file] -xml
[/path/to/file/or/directory]

A sample XMP export for a single file looks like this:

<x:xmpmeta xmlns:x='adobe:ns:meta/'>
<rdf:RDF
xmlns:rdf='http://www.w3.org/1999/02/22-rdf-syntax-ns#'
xmlns:rdfs='http://www.w3.org/2000/01/rdf-schema#'
xmlns:iX='http://ns.adobe.com/iX/1.0/'>

<rdf:Description
rdf:about='http://octane//chilly/files/myfile.jpg#'
xmlns:xap='http://ns.adobe.com/xap/1.0/'>
<xap:CreateDate>2004-03-26T21:52:19Z</xap:CreateDate>
<xap:ModifyDate>2004-03-26T21:52:21Z</xap:ModifyDate>
<xap:Format>application/data</xap:Format>
<xap:CreatorTool>Adobe Photoshop</xap:CreatorTool>
<!-- xap:Title is aliased to dc:title -->
<!-- xap:Author is aliased to dc:creator/*[1] -->
<!-- xap:Description is aliased to dc:description -->
<!-- xap:Keywords is aliased to dc:subject -->
<!-- xap:Rights is an aliased to dc:rights -->
</rdf:Description>

<rdf:Description
rdf:about='http://octane//chilly/files/myfile.jpg#'
xmlns:dc='http://purl.org/dc/elements/1.1/'>
<dc:description>This is myfile.jpg. It is a picture.</
dc:description>
<dc:format>application/data</dc:format>
<dc:creator>Xinet, Inc.</dc:creator>
<dc:title>myfile.jpg</dc:title>
<dc:subject>
<rdf:Bag>
<rdf:li>xinet</rdf:li>

202
 <rdf:li>fullpress</rdf:li>
<rdf:li>webnative</rdf:li>
</rdf:Bag>
</dc:subject>
</rdf:Description>

<!-- path/location information -->

<rdf:Description
rdf:about='http://octane//chilly/files/myfile.jpg#'
xmlns:stDsp='http://ns.adobe.com/xap/1.0/sType/FileDisposi-
tion#'
xmlns:xapS='http://ns.adobe.com/xap/1.0/s/'>
<xapS:ResourceID>
<rdf:Bag>
<stDsp:filename>myfile.jpg</stDsp:filename>
<stDsp:OS>Unix</stDsp:OS>
<stDsp:directoryPath>/chilly/files</stDsp:directoryPath>
</rdf:Bag>
</xapS:ResourceID>
</rdf:Description>

<!-- if the file is an image, the following should be included

-->

<rdf:Description
rdf:about='http://octane//chilly/files/myfile.jpg#'
xmlns:photoshop='http://ns.adobe.com/photoshop/1.0/'>
<photoshop:CaptionWriter>Xinet, Inc.</photoshop:Caption-
Writer>
<!-- photoshop:WebStatement is aliased to xapRights:Web-
Statement, which is not included in Venture-->
<!-- photoshop:Marked is aliased to xapRights:Marked, which
is not included in Venture-->
<!-- photoshop:Caption is aliased to dc:description -->
<!-- photoshop:Author is aliased to dc:creator/*[1]-->
<!-- photoshop:Title is aliased to dc:title-->
<!-- photoshop:Copyright is aliased to dc:rights -->
<photoshop:SupplementalCategories>
</photoshop:SupplementalCategories>
<!-- photoshop:Keywords is aliased to dc:subject -->
</rdf:Description>

<!-- end image inclusion -->

<rdf:Description
rdf:about='http://octane//chilly/files/myfile.jpg#'
xmlns:xwnv='http://ns.xinet.com/ns/xinetschema#'
xmlns:xwnvtmp='http://ns.xinet.com/ns/xwnvtmp#'>
<xwnv:FileID>75578</xwnv:FileID>
<xwnvtmp:ObjectName>myfile.jpg</xwnvtmp:ObjectName>
<xwnvtmp:Keywords>xinet
fullpress
webnative
</xwnvtmp:Keywords>
<xwnvtmp:Byline>Xinet, Inc.</xwnvtmp:Byline>

203
 Chapter 18: Using the export function in WebNative Venture

<xwnvtmp:Caption>This is myfile.jpg. It is a picture.</xwn-

vtmp:Caption>
<xwnvtmp:CaptionWriter>Xinet, Inc.</xwnvtmp:CaptionWriter>
<xwnvtmp:onoroff>1</xwnvtmp:onoroff>
<xwnvtmp:boolean-check>0</xwnvtmp:boolean-check>
</rdf:Description>

<rdf:Description
rdf:about='xwnvtmp:ObjectName' xmlns:
xwnv='http://ns.xinet.com/ns/xinetschema#'
xmlns:xwnvtmp='http://ns.xinet.com/ns/xwnvtmp#'>
<xwnv:string xwnv:description='IPTC-NAA Record 5' />
</rdf:Description>

<rdf:Description rdf:about='xwnvtmp:Keywords'
xmlns:xwnv='http://ns.xinet.com/ns/xinetschema#'
xmlns:xwnvtmp='http://ns.xinet.com/ns/xwnvtmp#'>
<xwnv:string xwnv:description='IPTC-NAA Record 25' />
</rdf:Description>

<rdf:Description
rdf:about='xwnvtmp:Byline' xmlns:xwnv='http://ns.xinet.com/
ns/xinetschema#' xmlns:xwnvtmp='http://ns.xinet.com/ns/xwn-
vtmp#'>
<xwnv:string xwnv:description='IPTC-NAA Record 80' />
</rdf:Description>

<rdf:Description
rdf:about='xwnvtmp:Caption'
xmlns:xwnv='http://ns.xinet.com/ns/xinetschema#'
xmlns:xwnvtmp='http://ns.xinet.com/ns/xwnvtmp#'>
<xwnv:string xwnv:description='IPTC-NAA Record 120' />
</rdf:Description>

<rdf:Description rdf:about='xwnvtmp:CaptionWriter'
xmlns:xwnv='http://ns.xinet.com/ns/xinetschema#'
xmlns:xwnvtmp='http://ns.xinet.com/ns/xwnvtmp#'>
<xwnv:string xwnv:description='IPTC-NAA Record 122' />
</rdf:Description>

<rdf:Description
rdf:about='xwnvtmp:onoroff'
xmlns:xwnv='http://ns.xinet.com/ns/xinetschema#'
xmlns:xwnvtmp='http://ns.xinet.com/ns/xwnvtmp#'>
<xwnv:bool xwnv:description='on or off' xwnv:booldisplayfor-
mat='checkbox' />
</rdf:Description>

<rdf:Description
rdf:about='xwnvtmp:boolean-check'
xmlns:xwnv='http://ns.xinet.com/ns/xinetschema#'
xmlns:xwnvtmp='http://ns.xinet.com/ns/xwnvtmp#'>
<xwnv:bool xwnv:description='' xwnv:booldisplayfor-
mat='checkbox' />
</rdf:Description>

204
 </rdf:RDF>
</x:xmpmeta>

Because XMP is a standard based on XML, it is readable by more than just Adobe’s suite of
products. You can also use this format for import into some XML-aware applications.

205
 Chapter 18: Using the export function in WebNative Venture

206
 When do existing FlashNet indices get read?

Chapter 19

Using WebNative Venture and FlashNet

One of WebNative Venture’s key features is its ability to store previews and FPOs for
images archived with FlashNet, and allow users to add metadata to all archived files. This
chapter will address common questions about the interaction between these two products.

When do existing Existing FlashNet indices for files that were archived prior to the enabling of a WebNative
FlashNet indices get Venture volume are read into the database during the initial syncvoltodb(1M) process.
read? When this happens, globald must be running to provoke WebNative Venture to query the
indices for information about files and previews.

What kind of previews There are three kinds of previews stored by WebNative Venture for image files.
are stored for files
Small preview
archived with FlashNet?
Large preview
FPO

In addition to these previews, there are also previews that can be stored by FlashNet; these
are called the thumbnails and will be stored when you archive image files if the CAPTURE
THUMBNAILS option has been turned on in the .dtool_env configuration file. In a regular
WebNative volume that is not WebNative-Venture enabled, FlashNet thumbnails allow the
user to see a preview of each image file.

When you enable WebNative Venture on a web volume, thumbnails are read into the data-
base as small previews. Therefore, even files that were archived before Venture was enabled
can have small previews stored in the database.

Sometimes it can happen that the stored previews are deleted or become corrupt. Small pre-
views can be recovered for archived files that were stored with the thumbnail capture fea-
ture turned on using the -archpicts flag as described in“Case 3: Archived files are in the
database but their previews are not” on page 210. However, large previews and FPOs can-
not be re-read into the database for archived files from FlashNet as they are not being stored
all. In order to get a stored preview back into the database, the file should be restored. After
that, the preview(s) need to be recreated, and finally WebNative Venture needs to store the
previews again in the database.

Additionally, if a file is placed on a server running WebNative Venture and FlashNet, and
the file is archived before WebNative Venture gets the preview information, the file will
show only a Xinet at Work image when the volume is browsed. Again, the only solution is
to restore, re-read the preview, and re-archive the file.

What’s special about Large previews are generated by FullPress for images and can be stored in WebNative Ven-
large previews? ture for later use. When the previews are stored, anyone browsing a Venture volume in
WebNative can click on images to display a large preview.

207
 Chapter 19: Using WebNative Venture and FlashNet

Before WebNative Venture, once an image was archived, the only preview available to
users is the small preview (also called a thumbnail”). Should a user wish to view the large
preview, the file would have to be restored. Now, for all Venture volumes that have the
Store Large Preview option turned on, this preview will be stored in the database for access
later, even once the file has been archived.

This same principal applies for FPOs, which can also be stored. The important thing to
remember for all stored previews is that they take up a great deal of disk space. For some
users, the ability to preview or even download FPOs of archived items outweighs the extra
cost of storage space.

The fact that large previews are not stored by FlashNet means that should they be removed
from the database, the only way to get them back is to restore the file, let the preview get
generated and re-stored, and then archive the file again. This is messy and has the undesired
result of causing two archives of a file to exist. If you are storing large previews (bigweb
previews), you should pay special attention to “Case 4: Archived and live files alike need to
be synchronized” on page 210. This describes the usage for the -noarchpicts flag which is
used to prevent small and large previews alike from being deleted when performing a -del
or -delnorm synchronization. (See “Syncs: to -delnorm or not to -delnorm” on page 248 for
more information)

Should globald keep WebNative and FlashNet used to rely on a daemon installed in the /usr/etc/webnative/plu-
running? gins directory called globald to ensure that archives were displayed properly when users
browsed web volumes. With the advent of WebNative Venture, one can store information
about archives and not require globald to be queried all of the time. While globald’s role
has changed, it is still necessary that it run in order to fully support archives. Here's why:

1. When WebNative Venture is first installed, it tests for the existence of a file called
globald.sync in the flashnet5/database/process_logs directory to confirm that FlashNet
is present on the server.
2. Most syncvoltodb(1M) processes consult globald for information about archives. The
listdir CGI is the exception to this rule; it will work without globald, but if it is running,
listdir can sync archives as well. (See“Database synchronization” on page 243 for more
information on sync processes.)
3. If for some reason the database is not available to provide information about archives in
a particular path, WebNative will query globald. The globald daemon will in turn
provide that information to the user via the browser.

How do the archivefile, There are several tables that store information about archives, backups and the media that
archivemedia, stores both of them.
archivepath, backupfile
and backuppath tables The archivemedia table stores the names of each piece of media used in the changer, as well
work? as its state. Online means in the drive, Nearline means in the changer but not loaded into the
drive and Offline means not in the changer. In order to keep this table up-to-date, it is impor-
tant to move tapes into and out of the changer using the FlashNet GUI, as it sends messages
to WebNative Venture about the location and state of tapes, both reflected when users
browse.

208
 How can I resync my archived files?

The archivefile and archivepath tables contain entries for archived files and folders. Each of
these items also has a corresponding entry in the file and path tables which is used as a ref-
erence to these entries. For example, archivefile entries are cross-referenced by the file
tables FileID, while archivepath entries are cross-referenced by the path table’s PathID.
This same pattern is followed by the backupfile and backuppath tables and their entries—or
at least, it will work this way once that functionality is implemented. For now, though, the
backupfile table will store entries for files that are backed-up, but until special code is added
to FlashNet to make it report backed-up paths to WebNative Venture, the backuppath table
will remain unused.

Essentially, when a file is archived or a sync gathers information on archived files, that
information is reported to the database. First, the media name is recorded (if new) or veri-
fied (if existing). Then the information about the file that is being archived or backed-up is
inserted into the appropriate table. When browsing a WebNative Venture volume, the files
and folders that are in the path being displayed come from the database. If an archived file
is in a path, it will be shown when browsing along with any live files that may exist there
too.

How can I resync my There are some special syncvoltodb(1M) flags that can be used if you want to sync
archived files? archived files that do not show in a particular location when browsing a WebNative-
Venture-enabled volume.

One of these flags, -dir, is the source of a great deal of confusion. Generally, the -dir flag should
be used along with other sync flags only when syncing archives. It should only be used
when the path being synchronized is not already stored in the database. The -dir flag tells
the syncvoltodb(1M) process that the path being synchronized is a directory. This causes the
directory to be entered into the database, but its contents will not be added. That means that
once you perform a -dir sync of a particular path, you may on occasion need to run the same
sync again, but without the -dir flag; the first sync gets the missing parent path into the data-
base, and the second sync takes care of the files and subpaths of that parent path.

This may be confusing, but the important thing to remember is that it’s best not to use the -
dir flag in your initial sync as it’s most likely that the path being synchronized is already in
the database. Alternately, you can run two syncs—one with the -dir flag and then one immedi-
ately following without the -dir flag. That should properly synchronize the files and sub-
paths in the path given to syncvoltodb(1M).

Please keep this information in mind while reading the five cases that follow. The first
example shows the use of the -dir flag, but for clarity’s sake the remaining four examples do
not. If in the course of running the other types of syncs you find that the parent path is not
stored in the database, you may add the -dir flag to the sync of your choice.

CASE 1: Archives need to be synchronized without concern for stored previews

For example, if you know archives exist in a directory but don't want to synchronize the
entire volume, you can run this command:
/usr/etc/venture/bin/syncvoltodb -delnorm path_to_directory

where the path above is replaced with the path to the level above the archives.

209
 Chapter 19: Using WebNative Venture and FlashNet

If this kind of sync doesn't work, you will need to add the -dir flag to the command above,
so that it looks like this:
Please note that this should be //usr/etc/venture/bin/syncvoltodb -delnorm -dir path_to_directory
typed on a single line.

where the path above is replaced with the path to the level above the archives.

The -delnorm flag will change the state of all files in the directory to offline (as in not view-
able through WebNative Venture) and then make sure that they are correctly entered into the
database with the correct state. This applies to both live and archived files. For more infor-
mation on the -delnorm flag for syncvoltodb(1M), consult “Syncs: to -delnorm or not to -
delnorm” on page 248.

In the event that the -dir flag was necessary to get the path entered into the database, then
you should run a sync immediately after using the -delnorm flag:
usr/etc/venture/bin/syncvoltodb -delnorm path_to_directory

where the path above is replaced with the path to the level above the archives.

Case 2: Archived files need to be synchronized but FlashNet previews are corrupt

If you try to synchronize an archived file, but the sync fails, then it could be the fault of a
corrupt FlashNet thumbnail which cannot be read by the syncvoltodb(1M) program.

The following type of sync will allow the archives to be updated even when they have a cor-
rupt preview. You can run the syncvoltodb(1M) command with the
-archonlynopicts flag (in addition to -dir) to make sure that the file gets added.

Please note that this should be /usr/etc/venture/bin/syncvoltodb -delnorm -archonlynopicts

typed on a single line.
path_to_directory

where the path above is replaced with the path to the level above the archives.

Case 3: Archived files are in the database but their previews are not

In the event that the archives are already coming from the database (which can be verified
by consulting the page source) and the previews for the archives are not, then you can do
the following kind of sync using the -archpicts flag. This will read in the picts again without
having to do a sync of the file information itself:

Please note that this should be //usr/etc/venture/bin/syncvoltodb -delnorm -archpicts

typed on a single line.
path_to_directory

where the path above is replaced with the path to the level above the archives.

Case 4: Archived and live files alike need to be synchronized

Another possibility is that you want to sync a folder that contains both live and archived
files without reading in preview information. In this case, you can use the -noarchpicts flag,
like this:

210
 How can I resync my archived files?

Please note that this should be //usr/etc/venture/bin/syncvoltodb -delnorm -noarchpicts

typed on a single line. path_to_directory

where the path above is replaced with the path to the level above the archives]

Case 5: No archive file information should be read into the database, even though it
exists

Last but not least is the case in which you do not want to read in any information about
archives. The instances in which you’d need to do this are few, but the syntax is as follows,
should it be necessary:

/usr/etc/venture/bin/syncvoltodb -delnorm -noarch path_to_directory

where the path above is replaced with the path to the level above the archives.

When browsing the results of this sync, you should see all online items updated, but the
archived ones will remain untouched—in the same state that they were prior to the sync.

211
 Chapter 19: Using WebNative Venture and FlashNet

212
 When the file system and the database don't match

Chapter 20

Troubleshooting WebNative Venture

WebNative Venture is complex, and as such there are different ways that things can go
wrong. This chapter addresses those issues and tools with which to gather meaningful infor-
mation about problems and solve them.

The issues discussed include:

• The mysqld daemon can’t be restarted.
• The database tables can be corrupt.
• Events cannot be added to the database.
• Particular events can stop being added correctly to the database.
• The contents of the file system may not necessarily match what’s in the database (usu-
ally only in one area of the database).
• Searches can be slow.
• Search results can be incorrect.
• WebNative programs start consulting the file system rather than the database.
• Particular events can be processed very slowly by the database (or never get processed).

In order to address these issues (and others like them) it helps to have a general idea of how
to get meaningful information from a “broken” database. The next section will deal with
some general things to look for when you begin troubleshooting. If you need an introduc-
tion to the binaries that do most of the work in WebNative Venture, see “Database synchro-
nization” on page 243 and “More information about the dblogd(1M) daemon” on page 100.

When the file system and This section covers a scenario common to some older WebNative Venture installations in
the database don't match which files on the file system were not accurately reflected in users’ browsers. If this occurs,
you should look at three things:

1. Is there a backlog of webdblog files? Check these locations for the existence of more
that one of these log files:
• UNIX: /var/adm/appletalk
• Windows: C:\Program Files\Xinet\FullPress
2. If there is only one webdblog file, event processing is probably up-to-date. If there is
more than one, you should verify that dblogd(1M) (the database daemon) is running.
In the WebNative nativeadmin GUI, go to the Database tab and select the Daemon page.
This will report the current state of dblogd(1M), either Running or Stopped. If it is
stopped, you can click on the Restart Daemon button to start dblogd(1M). It will then
read through the accumulated webdblog files and add missing changes to the database.
These will then show up to users as they browse WebNative.
3. If dblogd(1) is not running—and, restarting it did not fix the problem—put the daemon
in debug mode and send its log file to Xinet Technical Support for further investigation:

213
 Chapter 20: Troubleshooting WebNative Venture

a. Stop the daemon if it is running:

UNIX: /usr/etc/venture/bin/dblogd -k
Windows: \PROGRA~1\Xinet\Venture\bin\dblogd -k

b. Next, verify that it has stopped:

UNIX: ps -ef | grep dblogd

Windows: Look inside the Task Manager/Processes GUI for dblogd

The process should not be running.

c. Start the daemon again, this time in debug mode:

UNIX: /usr/etc/venture/bin/dblogd -D >& /tmp/dblogd.out

where /tmp/dblogd.out is the name of the file to which dblogd(1M) will write its
output

Windows: \PROGRA~1\Xinet\Venture\bin\dblogd -D 2> dblogd.out

where dblogd.out is the name of the file to which dblogd(1M) will write its output

d. Recreate the problem (or simply let the daemon die if that happens to be the issue).

e. Stop the debugging process by repeating step a. (above).

f. Finally, restart dblogd(1M) normally by using the nativeadmin Database tab >
Daemon window > Restart Daemon button.

Your debugging output can be sent to Xinet Technical Support, along with a detailed
description of the problem, for analysis.

Other important Asking the following might help:

questions to ask when
• Is the page seen when browsing WebNative drawn from the database or the file system?
troubleshooting Venture
issues You can check the page source for this information: most browsers allow you to search
the page source when you’ve opened it. Try searching for the text db. If nothing
matches this string, then the files on that page are coming directly from the file system,
which will be marked with the notation fs (for file system) or gd (for globald).
• Is dblogd(1M) running?
To determine if the dblogd(1M) daemon is running:

UNIX: ps -ef | grep dblogd

Windows: Check for dblogd.exe in the Task Manager

• Is the database running?
To determine if the mysql daemon is running, you can do the following:

UNIX: ps -ef | grep mysqld

Windows Check for mysqld-nt.exe in the Task Manager

214
Other important questions to ask when troubleshooting Venture issues

Another clue is that if the Admin window contains only “undefined” values, then the
database is not running, or is running but a connection to it from WebNative cannot be
made.
• Is the database accessible at all?
Try logging in on the command line using:

UNIX: /usr/etc/venture/bin/mysql -u root -p

Type the password at the prompt.
Type: use webnative;

Windows: \Program Files\Xinet\Venture\Bin\mysql -u root -p

Type the password at the prompt
Type: use webnative;
If this login succeeds, then the database is running and a connection can be made on the
command line, at least.
• Is a synchronization process underway?
A synchronization process can take many forms (described in “Database
synchronization” on page 243).
Here's how to look for a running sync process:

UNIX: ps -ef | grep syncvoltodb

ps -ef | grep userperms
ps -ef | grep dblogd

Windows: Check for syncvolotdb.exe in the Task Manager.

Check for userperms.exe in the Task Manager.
Check for dblogd.exe in the Task Manager.
• Is a database backup underway?
To determine if a backup process is running:

UNIX: ps -ef | grep dbmgr

The dbmgr process will run with the flag -quickbackup
or -fullbackup.

Windows: Check for dbmgr.exe in the Task Manager.

• Is FullText index creation underway?

UNIX: ps -ef | grep dbmgr

The dbmgr process will run with the flag -addfilenameindex

Windows: Check for dbmgr.exe in the Task Manager.

You can also check for the presence of the file #sql_XXXXX.MYI in the WebNative
Venture data directory. This is the temporary file where the FullText index is being
created.

215
 Chapter 20: Troubleshooting WebNative Venture

• Are files being added behind dblogd(1M)’s back?

Check the venture.log file (described in “The venture.log and venturelog.old files” on
page 218) for messages about out of sync in directories that have been modified with
files without using ksd(1M), any of the other Xinet “ks” utilities or WebNative Venture.
If this is the case, and if you are regularly using shell scripts, FTP uploads, SMB or NFS
mounts or any other method to get files onto your WebNative-Venture-enabled volumes
not using ksd(1M), Xinet “ks” utilities or WebNative Venture, then please see Xinet
TechNote 161: Keeping SMB/NFS Volumes in Sync for more detail on using this kind of
workflow with WebNative Venture.

Further steps for More questions to consider:

troubleshooting
• How do I sync a small area of WebNative Venture?
If a single directory or path is not in sync with the file system, then you can run this
command to force a sync on that path:

UNIX: /usr/etc/venture/bin/syncvoltodb -delnorm path_to_dir

Windows: \Program Files\Xinet\Venture\Bin\syncvoltodb.exe -delnorm

path_to_dir

If this fails, syncvoltodb(1M) will write errors into the WebNative venture.log file.
These can be valuable as they may indicate why a particular path cannot be brought into
sync with the file system.
Important note: If the path on which you are running a syncvoltodb(1M) process is not
the path to the top level of the volume, then the -dir flag should be added to the
command above, just after syncvoltodb.
• How do I turn off the database (briefly)?
Sometimes, the only way to determine if a problem is WebNative-Venture-related is to
briefly shutdown its database. It is always best to do this from the WebNative
nativeadmin GUI via your browser. Go to the Database tab > Admin page and click the
Shutdown Database button. Restart the database from this same location when you are
done.
Alternately, you can shutdown the database on the command line using the dbmgr(1)
program:

UNIX: /usr/etc/venture/bin/dbmgr -shutdown

Windows: \Program Files\Xinet\Venture\Bin\dbmgr.exe -shutdown

To restart, simply substitute the word restart for shutdown above.

• How do I see what mysqld is processing right now?
A very simple way to monitor the database is to use MySQL’s processlist command.
This can be done from the command line only—either from within the database “client”
itself, or alone using the mysqldmin program. Directions for each method follow:

UNIX: /usr/etc/venture/bin/mysqladmin -u root

-proot_password processlist

216
Further steps for troubleshooting

Windows: \Program Files\Xinet\Venture\Bin\mysqladmin.exe

-u root -pPASSWORD processlist

The commands listed above will give you a grid in which the running process at that
moment in time is displayed (in other words, this utility does not provide dynamically-
updated output).
You can also get a more detailed list from within the client, as follows:

UNIX: /usr/etc/venture/bin/mysql -u root -p

At the Enter password: prompt, type the root password
After login in, type: use webnative;
show processlist;

For added detail, type: show full processlist;

Windows: \Program Files\Xinet\Venture\Bin\mysql -u root -p

At the Enter password: prompt, type the password
After login in, type: use webnative;
show processlist;
For added detail, type: show full processlist;

• How do I get a “status report” on the database?

Using the mysqladmin command, you can request a report on the status of the database
which will provide the information listed below. This can be useful for day-to-day
monitoring of the database, but more likely, can be referred to in the event that the speed
at which the database responds to queries is slow.

UNIX: /usr/etc/venture/bin/mysqladmin -u root

-proot_password status

Windows: \Program Files\Xinet\Venture\Bin\mysqladmin.exe

-u root -pPASSWORD status

The utility will report something like this:

Uptime: 530 Threads: 2 Questions: 9 Slow queries:

0 Opens: 10 Flush tables: 1 Open tables: 4 Queries
per second avg: 0.017

The variables have the following meanings:

Uptime = database uptime (in seconds)

Threads = current number of clients connected to the database
Questions = number of clients connected since the database was
started
Slow queries = the total number of queries that have taken more
than 10 seconds to be answered
Opens = number of open tables since the database was
started
Flush tables = the number of flushed tables
Open tables = the number of currently open tables

217
 Chapter 20: Troubleshooting WebNative Venture

Please refer to the MySQL web site at www.mysql.com for more information on these
variables and how they relate to database performance.

The venture.log and There are many different ways that you can get information about WebNative Venture and
venturelog.old files the MySQL database. WebNative Venture has one main log file where most errors are writ-
ten. This file, called venture.log and can be found in the following locations:

UNIX: /var/adm/appletalk

Windows:C: \Program Files\Xinet\FullPress

When a periodic syncvoltodb(1M) process is run, this log will be rotated, the
venture.log becoming venture.log.old. A new venture.log file will be created only when
there is something to report to it; i.e., a new log does not automatically get made.

It’s a good idea to check this log periodically, as any errors or problems will be reported
here. For example, errors about corrupt database tables will be written to this file as well as
feedback about other serious problems. For example, if you were to see this kind of entry in
venture.log (or .old):

Tue Apr 15 08:30:09]//Error: Can't open file: 'file.MYD'. (errno: 145)

Use the steps described in Xinet TechNote 147: Repairing Venture MySQL Tables to check
and repair the database.

The fpod_vlog file Unless you altogether turn off the Rotate and truncate FPO log option in FullPress, the
WebNative Venture server will automatically log some information from several Xinet pro-
grams, namely pdfsync, syncxmp, officesync, and movsync whenever a new file arrives on or
shows up in a new location on the server. The information will be written in a file called
fpod_vlog file, and you can find it in the following location:

UNIX: /var/adm/appletalk

Windows:C: \Program Files\Xinet\FullPress\admin

You may want to make special use of this log when you encounter problems with document
previews or with XMP metadata. Normally, the file will only contain information about
which file ID and location; but, you can manually cause more debugging information to be
written in the files as follows.

1. Open the fpod.conf file with a text editor. You’ll find the file in the following location:
UNIX:/usr/etc/venture/var
Windows:C:\Program Files\Xinet\Venture\var
2. The fpod.conf file provides the fpod(1M) daemon with information for managing the
previews it generates. Add a -D flag to the process for which you want to see more
debugging information. For example, if you wanted more information about PDF
preview generation, you would change the pdfsync entry to be:
18 $w/pdfsync -fid$i -volflags$f -D

218
 The SERVER.err file

3. Save and close the file

4. Then, look within the fpod_vlog file to see if you can determine the source of your
problems.

The fpod_vlog will be rotated on a weekly basis, with the older file being named
fpod_vlog.old. Each week, fpod_vlog.old will be overwritten.

NOTE FOR THOSE UPGRADING A VERSION OF WEBNATIVE VENTURE: If you have just
upgraded your server from a version of WebNative Venture prior to version 8.03, your
server won’t automatically generate a separate fpod_vlog file because the upgrade process
never changes pre-existing configuration options. To make sure this file can be written:

1. Open the FullPress Configuration GUI on your server.

2. In the File Service section, open: Status and Config/FPO Logging
3. Provide the Rotate and truncate FPO log to any value other than Never.
4. Save the setting.

The SERVER.err file MySQL startup and shutdown is logged to the SERVER.err file on a regular basis. (SERVER
is a variable that should be replaced by the name of your server.)

While WebNative Venture errors are reported to venture.log, sometimes MySQL itself also
experiences problems. Errors from the program are written in the following location:

UNIX: /usr/etc/venture/data

Windows: C:\Program Files\Xinet\Venture\data

If MySQL is unusable for some reason, or if you see an error has occurred in the Database
tab > Admin page of the WebNative nativeadmin GUI, you can check this file (as well as
venture.log) for errors.

The at_log file FullPress uses the at_log and at_log.old files to log errors. Venture can also use this log to
report licensing problems. As with the SERVER.err log, only on rare occasions will Ven-
ture-related errors appear in this file. However, it is still useful to check here should abnor-
mal behavior occur. at_log is located in:

UNIX: /var/adm/appletalk

Windows: \Program Files\Xinet\FullPress\Admin

Logs from WebNative WebNative Venture depends upon five daemons that in turn communicate with the
Venture queues FullPress fpod(1) daemon. They include:

mview which allows WebNative Venture to display previews of QuarkXPress

and InDesign files

219
 Chapter 20: Troubleshooting WebNative Venture

syncxmp which writes XMP information from files into the WebNative Venture
database

pdfsync which ensures that multipage PDF previews will be written into the data-
base

movysnc which is responsible for writing key frames from video files into WebNa-
tive Venture

officesync which helps provides previews of Microsoft Office documents for Web-
Native Venture

A FullPress option exists that cause the server to write information about these daemons
into a log file, /var/adm/appletalk/fpod_vlog (UNIX) and C:\Program Files\Xinet\Full-
Press\Admin\fpod_vlog.wri (Windows). You can monitor what’s going on and get a better
understanding of what may be causing problems by looking at this file.

The only perquisite for log-file creation is a single setting within the FullPress GUI, shown
in Figure 92. Within the FPOD Logging Options window, the setting Rotate and truncate
FPO log must have any of the possible settings except Never. If you are not seeing the
fpod_vlog file, check this setting.

FIGURE 92. Ensuring that fpod_vlog will be created

Use any available text editor to look at the file. Figure 93 presents a sample of what you
might see.

220
Logs from WebNative Venture queues

FIGURE 93. A sample fpod_vlog file

221
 Chapter 20: Troubleshooting WebNative Venture

222
Appendix A

Command-line manual pages

This appendix contains individual descriptions of programs which WebNative installs on

the server. The descriptions appear in alphabetical order. The same information also
appears on-line in the PDF version of the manual distributed with WebNative.

These programs were originally developed for the UNIX operating system, and while for the
most part, the descriptions of them are accurate for Windows systems, you may occasion-
ally find options or terminology which do not apply. Many of the file name paths may still
refer to UNIX systems, e.g., /usr/etc/appletalk,
/var/adm/appletalk, and /usr/etc/venture/bin. In most cases /usr/etc/appletalk maps to
C:\Program Files\Xinet\FullPress, /var/adm/appletalk becomes C:\Program
Files\Xinet\FullPress\Admin, and /usr/etc/venture/bin becomes C:\Program
Files\Xinet\Venture\Bin.

On UNIX systems, the manual pages printed in this section may be installed in the appropri-
ate directories for access with the UNIX man(1) command.

223
 : Command-line manual pages

224
 DBLOGD ( 1M )

NAME
dblogd – daemon responsible for sending information from FullPress and WebNative to the MySQL Web-
Native Venture database.
SYNOPSIS

dblogd [ – d dblev  – D ] [ – a ] [ – v  – k  – m mirror directory ] [ – s ] [ – p ] [ – u ]

DESCRIPTION
The dblogd(1M) daemon is responsible for transmitting events generated by FullPress and WebNative to
the MySQL WebNative Venture database. FullPress and WebNative programs write events into w ebdblog
files, located in the FullPress administrative directory. The dblogd(1M) daemon reads these w ebdblog files
and gives the events to m y sqld for processing.

When a sy ncv oltodb(1M) process is running, or when a backup of the database is being made by
dbmgr(1M), dblogd(1M) will be pa used. Events continue to be wr itten to the webdblog file. If that file
grows to 1MB, a second webdblog file will be generated. This continues until dblogd(1M) is unpaused (or
restarted if it was turned off). The dblogd(1M) daemon will read the oldest event first, working through
each w ebdblog file until all events have been passed to m y sqld. For example, if dblogd(1M) was off dur-
ing a period of high system activity, there could be a backup of three w ebdblog files:

webdblog
webdblog.0001
webdblog.0002

Since the events inside w ebdblog.0001 are the oldest, that file will be processed. When all events have
been read by dblogd(1M), that file will be deleted and the remaining files will be renamed. So, w ebdb-
log.0001 will be deleted, and w ebdblog.0002 w ill becom e w ebdblog.0001. N ex t, w ebdblog.0001 will be
processed in its entirety. When it has been processed, it too will be deleted, and dblogd(1M) will turn its
attention to w ebdblog, which it will read and process.
OPTIONS
The flags are defined as follows:

– d dblev
Turns on debugging at a certain level, represented by dblev (in hex).

–D Turns on full debugging.

–a sends debugging output to at_log(4)

–v Returns the version number for dblogd(1M).

–k Kills a running dblogd(1M).

–m Mirrors events from one server on another. This flag is used to synchronize two different
servers: one running FullPress and the other one running WebNative Venture. The
FullPress server generates WebNative Venture events from ksd(1M), mkfpo(1), etc.. The
WebNative Venture server generates events by means of listdir, uploads, etc.. For this rea-
son, events from both servers need to be merged. Enabled volumes must be synchronized,
as with NFS mounts or other shared filesystems; FullPress and WebNative Venture users

225
DBLOGD ( 1M ) Appendix A: Manual Pages

should be accessing the same volumes.

To make sure this mirroring of events takes place between the WebNative Venture server
and FullPress server, you have to:

1) Mount the /var/adm/appletalk directory from the WebNative Venture server to a

new location on the FullPress server via NFS.

2) Run the following on the FullPress server:

dblogd – m new location for the NFS mount

That way all the events generated on the FullPress server will be added to the
WebNative Venture server webdblog event log as well, causing the right updates in
the WebNative Venture database.

–s Keeps a copy of the event log files (webdblog.xxxx) for debugging purposes.

–p Pauses the currently running dblogd(1M) process.

–u Restarts the currently paused dblogd(1M) process.

EXAMPLES

dblogd
Runs the daemon and puts it in the background.

dblogd – k
Kills the current dblogd(1M) process.

dblogd – m /raid/wnvmount
Copies all local events to the directory /raid/wnvmount
FILES

/var/adm/appletalk/webdblog.xxxx
Log files containing unprocessed events.

226
 DBMGR ( 1M )

NAME
dbmgr – program for managing the WebNative Venture database

SYNOPSIS
dbmgr [ options ] [ actions ]
dbmgr [ options ] [ actions ] [. I target ]

DESCRIPTION
The dbmgr utility for WebNative Venture can be used to do general database maintenance as well as
specific administrative tasks from the command line. Most of these operations are generally done automat-
ically according to settings in the Database tabs of the WebNative nativeadmin GUI. The dbmgr utility
also includes flags to remove duplicates, and orphans from the database, as well as no-longer-needed
entries.

OPTIONS

– d dblev
Turns on debugging at a certain level, represented by dblev (in hex).

–D Turns on full debugging.

–v Turns on verbose reporting mode.

ACTIONS

– pass password – newpass newpassword

Changes the current MySQL database password (password) to a new password (newpass-
word).

– addindexes
Adds basic table indexes

– addnativeadmin
Adds the user "nativeadmin" to the MySQL database’s user table (called during installa-
tion).

– addshowdata
Adds "browse" to the permsetfield table. (This option can only be called from a brower.)

– archivemerge
Merges together archivemedia table entries for media that have more than one entry.

– buildfulltextindex path

Adds a FullText index to the FileName column of the file table using path as the tem-
porary location where the index will be built. Rather than blocking writes to the file

227
DBMGR ( 1M ) Appendix A: Manual Pages

table, it starts an entirely new copy of the mysqld daemon (running on a different socket)
which runs solely to build the index. The original (and otherwise fully-functional) mysqld
is restarted with the binary log turned on. (The binary log is a full log of all queries that
affect the database.)

Once the index is built by the side-running mysqld daemon, the original is also stopped
and the binary log changes are applied to the copy. At this point, the copy contains the
FullText index as well as all the changes to the database which occurred during the index
build.

In the final step, the copy is swapped into the location of the original and everything is
started.

Note that there will be a period where the database will be write-locked for the – build-
fulltextindex as well; but, since it is during the application of the binary log change, it will
be presumably much shorter than if you were to create the index from the option in the
nativeadmin GUI.

As you can imagine, disk usage is an issue. It is important that you have the index temp
directory on a disk with ample space. Note especially: performance will be aided greatly if
you have the temp directory on a different disk than the one that holds the database. (I/O
during the creation of the index will be intense.)

There is an additional measure of safety in using a separate disk, should there be a failure
or a crash during the indexing. Since the daemon is running on a copy, the copy could
simply be deleted and the original mysqld restarted (via the nativeadmin GUI) to turn off
unnecessary binary log generation.

– checkpathdups path
Checks for duplicate entries in the path table, and consolidates multiples into one.

– cleanbefore MM/DD/YYYY
Removes event table entries with a time earlier than MM/DD/YYYY. (The date must have
this format.)

– dbclean
Combines the functionality of – archivemerge, – checkpathdups, – fixoffline, – fixoprhans,
– pathclean, and – removeorphans. (Each of these may be run on an individual basis.)

– dropfilenameindex
Removes the FullText index from the file table.

– fixfiledups
Removes files from the file table that have both online and offline entries.

228
 DBMGR ( 1M )

– fixoffline path
Updates online state for files and folders, as appropriate based on filesystem.

– fixorphans
Removes files that do not have valid parent paths from the database.

– mergetrailingspaces [path]
Merges path table entries that are duplicated due to the existence of a trailing space in the
foldername. In the past, when folders with trailing spaces were renamed, duplicate entries
were made, one for each version of the path name. This command will fix that problem
for live paths.

– optimize table
Runs the MySQL optimize command on the specified table.

– pathclean path
Removes paths that no longer exist from the database.

[ – progress] – temp – path path

Moves the WebNative Venture temp directory to path. (This option can only be called
from a browser. It displays a progress bar to the user.)

[– progress] – data – path path

Moves the WebNative Venture data directory to path. (This can only be called from the
browser. It displays a progress bar to the user.)

– purgedeleted
Removes database entries for files that have been deleted and NOT archived. (ie. Online=0
and Archived=0)

– purgeevents
Removes entires from the event table when they meet the criteria set in the WebNative
nativeadmin GUI > Database Tab > Volumes page.

– purgeallevents
Removes all events from the event table.

– purgebackupevents
Removes all "backup" events from the event table.

– purgedeleted [– countonly]
Removes deleted (and unarchived) files from the database. Using – countonly will return
the number of files effected without actually removing the files, giving some idea of the
usefulness of using the flag.

– purgeemptykeys [– countonly]
Removes empty or NULL valued rows in metadata data table. Using – countonly will
return the number of files effected without actually removing the files, giving some idea
of the usefulness of using the flag.

229
DBMGR ( 1M ) Appendix A: Manual Pages

– purgenullkeys [– countonly]
Removes NULL valued rows in metadata. Using – countonly will return the number of
files effected without actually removing the files, giving some idea of the usefulness of the
flag.

– purgeunusedevents  – cleanupevents
Removes all "read" and "setfileparms" events from the event table.

[– nolock] – quickbackup
Run a quick backup of the database, which does a backup of all tables EXCEPT those that
store previews. The optional [– nolock] flag can be used to prevent the tables from being
locked when the backup is run. The default option is to NOT use this flag.

[– nolock] – fullbackup
Run a full backup of the database, which does a backup of all tables. The optional
[– nolock] flag can be used to prevent the tables from being locked when the backup is run. The
default option is to NOT use this flag.

– remove [– offlineonly]
– v – p – f – u – g – t – s – k – m objectname 
– remove [ – offlineonly ]
– vid – pid – fid – uid – gid – tid – sid – kid – mid object db id

(single letter removes an object by name,

letter plus "id" removes an object by id)
v = volume
p = path
f = file
u = user
g = group
t = template
s = permset
k = keyword
m = media

Removes the specified item from the database. This flag can be used to remove anything
from a file to a volume. It is generally best to follow a remove with the dbmgr
– dbclean command to truly purge the items and their related objects. You can use either
the name of the object that you want to remove (i.e., /raid/path/temp) or the object ID as
it exists in the database.

Examples:

dbmgr – remove – v MyVolume

dbmgr – remove – vid 20

230
 DBMGR ( 1M )

– removeallarchives
Removes all archive entries from the database including file, path, archive media and
archive event entries.

– removearchiveorphans
Remove archive entries without file or path table entries.

– removearchives path
Removes archive entries for a particular file or path (does not purge media information).

– removeorphans
Removes paths that do not correspond to an enabled volume (and their child files) from
the database; removes previews for volumes that exist but no longer have previews
enabled.

– restart  – start 
Restarts or starts the mysqld daemon. (Note: this does NOT restart dblogd. That must be
done in the GUI or by hand.)

– rundatetriggers
Force the execution of date triggers. Date triggers will be executed if the current time is
equal to or after the time in the date trigger table.

– setlang ja  fr  de  en  big5  gb2312  ko

Used to convert the strings and character sets used by the database to a certain language.
Once WebNative Venture has been installed, you can run this command to localize the
database into Japanese (ja), French (fr), German (de), Traditional Chinese (big5), Simplified
Chinese (213), Korean (ko), or back into English (en) from some other language.

– setvar v ar iab le=v alu e

Used by dbmgr when called as a CGI. (This can only be called from a browser.)

– setvarnorestart variable=fIvalue
Sets mysqld config variable without restarting mysqld.

– shutdown
Shutdown the mysqld daemon. (Note: this also stops dblogd, which cannot be running
without mysqld.)

– start
Starts the mysqld daemon. Same as -restart.

– temp – path path

Sets mysqld temp directory path.

– updatetables
Updates tables to latest version, using dbtables.sql and dbtemplate.sql scripts in the Venture
scripts directory.

231
DBMGR ( 1M ) Appendix A: Manual Pages

– updateusersettings
Updates user.conf files. Determines the user list on the WebNative server and makes sure
that each entry has an entry in the database

– updatevolumes
Update the volume table with the latest volume information from KASPubVols. Old
volumes that are no longer WEB-enabled will be deleted, and their contents removed.

– updatewnperms
Update the webnativeperm table with the contents of the webnativeperm file.

– updatexmp
Adds columns to keyword1 for XMP fields defined in the keyword table. Only needed if
those columns don’t exist in keyword1 for some reason.

– version
Reports the version of MySQL and of the data tables. Also produces checksums for
installed binaries.
FILES

/usr/etc/venture/bin/dbmgr

232
 MOVSYNC ( 1M )

NAME
movsync – responsible for sending previews of video frames from FlipFactory and ffmpeg to the Xinet
WebNative Venture MySQL database.
SYNOPSIS
movsync [ – d dblev  – D ] [ – fid#### ] [ – volflags### ] [ – n## ] [ full file path ]
DESCRIPTION
The m ov sy nc(1M) program is responsible for sending previews of video frames from FlipFactory and
ffmpeg to the Xinet WebNative Venture MySQL database. Xinet FullPress and WebNative programs write
events into w ebdblog files, located in the FullPress administrative directory. The dblogd(1M) daemon
reads the w ebdblog files, and when it finds a match to a m ov ie file type listed in the Xinet file-type library
(/usr/adm /appletalk /fi lety pe), dblogd(1M) gives the file to f pod(1M) for processing. The f pod(1M) daemon
then calls m ov sy nc(1M) to process each movie. Before it does so, m ov sy nc(1M) runs a second match-
comparison based on the file extensions it finds in the m ov sy nc.conf file. With each match, it creates key-
frame previews for the WebNative Venture database.

The m ov sy nc(1M) program is configured through the tab-delimited m ov sy nc.conf fi le, located in the
/usr/etc/venture/var directory on Unix systems and C:\Program Files\X inet\V enture\v ar\ on Windows sys-
tems. Here is a sample:
0.0.0.0 userid password factory 9000 15 128 mpeg,mpg,mov,
Here is what each entry governs:

0.0.0.0
The IP address of the movie processing server. Use 0.0.0.0 if processing with local ffmpeg
support.

userid/passw ord
Used for FTP transfer of the movie and access to the FlipFactory workflow.

f actory
Name of the factory configured for movie processing on the FlipFactory server.

9000 FlipFactory server port assignment. 9000 is the default.

15 For the FlipFactory server, this is the recheck for progress interval (in minutes). For
ffmpeg, this is the frames-per-second interval.

128 The number of key frames that m ov sy nc(1M) will put in the WebNative Venture database, the
default being 128, which can be increased to a maximum of 256.

mpeg,mpg,mov
A comma-delimited list of file extensions to process.

COMMAND OPTIONS
The flags are defined as follows:

233
MOVSYNC ( 1M ) Appendix A: Manual Pages

– d dblev
Turns on debugging at a certain level, represented by dblev (in hex).

–D Turns on full debugging.

– fidFileID
The WebNative Venture file identification number (in decimal) for the file to be processed.
A file path is not needed when a FileID is supplied.

– volflagsflags
Optional decimal volume information flags (normally pulled from the Venture database).

– ncount
Movsync is called repeatedly for the same file to monitor its progress. This options passes
the process execution count of a particular file, starting with 0 as first occurrence.

– f ull fi le path
While not as sure as identifying the file by its file identification number, you may supply
the f ull fi le path alone, letting m ov sy nc(1M) supply the file identification number. If it cannot
associate a number with the name, m ov sy nc(1M) will exit.

EXAMPLES

movsync – fid316 – n0
Process file ID 316 for the first time. This tells m ov sy nc(1M) to send the file to FlipFactory for
processing.

dblogd – fid316 – n2
Third execution of file ID 316. When used with FlipFactory, this indicates to movsync(1M)
that it needs to check for progress on the file.

FILES

/usr/etc/venture/bin/movsync

/usr/etc/venture/var/movsync.conf

234
 PDFSYNC ( 1M )

NAME
pdfsync – stores previews of PDF pages into the Xinet WebNative Venture database.
SYNOPSIS
pdfsync [ – D  – d dblev ] [ -fid#### ] [ – volflags#### ] [ filepath ]
DESCRIPTION
The pdfsync program is responsible for storing previews of pages — and placed-image information —
from PDF files into the Xinet WebNative Venture database. The previews are used by WebNative’s
mview CGI to show the PDF and its placed images in a browser. Xinet FullPress and WebNative pro-
grams write events to webdblog files, located in the FullPress administrative directory. The dblogd(1M)
daemon reads the webdblog files and when it gets notification of a new or modified PDF file, and
if storing multi-page previews is enabled for the volume containing the PDF, webdblog sends a
message to the fpod (1M) daemon for processing. Fpod then calls pdfsync to process one PDF file
at a time. See the fpod.conf file for the calling sequence fpod uses for pdfsync.

Previews are generated using FullPress’ PostScript/PDF interpreter, and parameters controling
the size and type of preview are taken from the fpovolopts(4) entry for the volume. If it takes
longer than 10 minutes to make any single preview, that page preview is skipped. Only the
previews configured to be stored for the Venture volume (i.e. ‘‘large’’ and/or ‘‘small’’) are
made.

Pdfsync writes log messages about the files it processes to stdout, which is usually redirected to
the fpod_vlog file in the FullPress administrative directory. If debugging is enabled, those mes-
sages go to stderr, which is also usually redirected to fpod_vlog. The exit status from pdfsync
will be zero on success or if it cannot resolve a given FileID to an actual file stored in the Ven-
ture database. All other error conditions will result in an exit status of 1 (which tells fpod to
retry the file).
COMMAND OPTIONS
The flags are defined as follows:

– d dblev
Turns on debugging at a certain level, represented by dblev (in hex).

–D Turns on full debugging.

-fidFileId
Supplies the WebNative Venture file identification number FileId (in decimal) for the file
to be processed. Specify either a FileId or a filepath - but not both - to sync a PDF.

– volflagsflags
Optional volume information flags (also in decimal). Normally, these flags are retrieved
from the Venture database.

filepath
If syncing a file ‘‘by hand,’’ its full path may be used instead of the FileID. If pdfsync can-
not resolve the Venture File ID from the path, it will exit with a non-zero value.

235
PDFSYNC ( 1M ) Appendix A: Manual Pages

FILES

/usr/etc/venture/bin/pdfsync

/usr/etc/venture/var/fpod.conf

/var/adm/appletalk/fpod_vlog

236
 SYNCVOLTODB ( 1M )

NAME
syncvoltodb – manually synchronizes information about files in the file system with the WebNative Ven-
ture database

SYNOPSIS

syncvoltodb [ options ] [ actions ] [ path  – i input fi le  – f file  – dir ]

DESCRIPTION

The syncvoltodb(1M) program, used to manually synchronize information about files in the file system to
the WebNatve Venture database, can be given a path, a text file containing a list of paths or a single file
to update. For a normal synchronization not using the – del or – delnorm flags, syncvoltodb(1M) will
check the modification dates of files in the database to decide whether to rescan a folder’s information.

OPTIONS

– fg Runs syncvoltodb(1M) without forking child processes for each new file.

–D
Turns on full debugging output to standard error.

– dir A hint used to indicate that a path is a directory and not a file. Only used for archived
paths that are no longer on the file system.

– sql
Turns on SQL query debug output.

– logic
Turns on normal debugging output.

– nodaemon
Prevents the backgrounding of the process.

– bg
Run the synchronization while temporarily disabling access to WebNative Venture infor-
mation during the process. The information returned will come directly from the filesys-
tem.

– hsm
Does an HSM-compatible synchronization that prevents offline data from being staged. It
will try to populate only the file information that is available in the nearline resource
information. You won’t get previews nor XMP data, etc.

– skiptop
Use – skiptop to synchronize only the contents of a folder without synchronizing the parent folder
itself.

237
SYNCVOLTODB ( 1M ) Appendix A: Manual Pages

ACTIONS

– del
Runs a full resynchronization of all files, presetting files offline before resynchronizing all
of the files in the given path. This will also run the equivalent of a dbmgr – dbclean which
removes various types of orphaned or duplicated database entries.

– noarch
Will synchronize only online files.

– archonlynopicts
Will synchronize only the file information of archived files, skipping the reading in of the
small preview data.

– archpicts
This reads in the small preview data of the archives in the given path.

– noarchpicts
Skips the synchronization of archive previews but does the online and archived file infor-
mation.

– noconvert
Indicates that the data should not be converted. Used for special 2-byte languages like
Japanese.

– archflag
Synchronizes the "Archived" flag of the file table to indicate whether the file has an
archive. Only used to update older versions of the database that did not support the flag.

– force
Force the synchronization of paths that are not currently WebNative Venture enabled.

– delnorm
Same as – del without the dbmgr – dbclean. ,TP – noxmp Prevents reading a file’s XMP
information

– xmponly
Updates the XMP data for the files (and implicitly the file table). Must not be used in con-
juction with other flags.

– moov
Synchronizes video files, if they are enabled. If the file has already been marked as being
in sync, i.e., the mod time are the same, this will not force a resyncing of file data.

– pdf Synchronizs PDF files, if multipage PDF view is enabled. If the file has already been
marked as being in sync, i.e., the mod time are the same, this will not force a resyncing of
file data.

238
 SYNCVOLTODB ( 1M )

PATH

path  – i in p u t fi le  – f
By supplying a path you direct syncvoltodb(1M) to a particular directory or volume to be
synchronized. With input file, syncvoltodb(1M) uses a text file which should contain a list of
paths (one per line) to directories or volumes. Using – f fi le in front of a list item allows you
to specify a file as the target for a synchronization.

FILES

/usr/etc/venture/bin/syncvoltodb

239
VENTURELOG ( 1M ) Appendix A: Manual Pages

NAME
venturelog – when the state of the filesystem changes, takes command-line arguments and sends
dblogd(1M) events

SYNOPSIS

venturelog [ – u username ] [ – a IP_Address ] action

DESCRIPTION

Some stages of your workflow may include custom scripts or programs that alter the state of the
filesystem. It is necessary to keep WebNative Venture informed of these changes, so it can
correctly display images and other files to web clients. You could accomplish this by using
syncvoltodb(1m) after any changes to the filesystem occur, but a full update of the system with
this program would be a time-consuming process. Using venturelog(1m) provides a better
option. The venturelog(1m) program takes command line arguments that send dblog(1M) events
in the same way other Xinet programs do.

OPTIONS

– u username
allows you to specify the name of web user who performed the action. This parameter is
optional and its value is only shown in the detailed history tab in WebNative.

– a IP_Address
allows you to specify the IP address whence the event comes. This parameter is optional
and its value is only shown in the detailed history tab in the WebNative Venture GUI.

ACTION

– create filename
establishes that filename has been created in a WebNative Venture enabled volume

– delete filename
establishes that filename has been removed from a WebNative Venture enabled volume.
Note: If it has been moved to the trash, use – rename instead. Then use – delete when the
trash can is emptied.

– rename filename filename2

filename has been renamed or moved to another path. This event takes two filenames,
source and target.

240
 VENTURELOG ( 1M )

– read filename
filename has been opened and closed for read-only access. This event only checks for the
existence of a record in the database and might be omitted.

– write filename
filename has been opened and closed and there was at least one write operation to it. Issue
this event when a file has been modified and closed.

– copy filename filename2

filename has been copied to another path or filename. This event takes two filenames,
source and target.

– mkdir filename
A new directory has been created with the name filename

– rmdir filename
A directory, filename, has been deleted. This event does not affect any child of the deleted
directory. You will need to send delete events for each element inside the directory before
sending – rmdir fi lenam e.

– addcmt filename
The Mac finder comment has been added or modified for this file.

– setparms filename
Mac finder parameters have been modified for filename, e.g., directory position, locked
status, etc. This event only signals that another program has changed the parameters. It
doesn’t change them itself.

– fpo filename
FPO created for filename.

– webimage filename
WEB created for filename.

– quarkimage filename
Web preview created for a QuarkXPress or InDesign document with the name filename.

– pdfimage filename
PDF preview created for filename.

– pubvols
The list of Xinet Appleshare volumes has been altered. filename parameter is ignored.

– downhires filename
User has downloaded a copy of the hires for this image.

– downfpo filename
User has downloaded a copy of the FPO for this image.

241
VENTURELOG ( 1M ) Appendix A: Manual Pages

– downprev filename
User has downloaded a copy of the web preview for this image.

– upload filename
filename has been uploaded to the WebNative Venture server.

– imageordr filename
filename has been custom ordered from the WebNative Venture server.

– backedup filename
filename now has a backup. You must specify if filename is a file or a directory (isfile or
isdir). You can optionally specify the name of the media where the backup has been made
(– m media name). This does not imply that the original in the filesystem is gone. If you are
archiving the file, use – backedup after transferring to tape or CD and then – delete when
you delete the file from the filesytem.

– online filename
filename has been restored from a backup/archive.

– mediachg media_name online  nearline  offline

media name has changed state to online, nearline or offline.

– tapedel media_name
media_name has been discarded and all the backups in that media have been lost.

– print filename
filename has been printed.

– archived fi lenam e isdir  isfile [– m m edianam e]

fi len am e has been archived. You must specify if fi len am e is a file or a directory (isfile or
isdir). You can optionally specify the name of the media where the archive has been made
(– m media_name).

– sync filename "extra_syncvoltodb_parameters (use double quotes)"

filename should be synced, using the extra parameters passed in double quotes.

EXAMPLES

venturelog – write mynewfile.pdf

venturelog – archived isfile – m tape009 myarchivedfile.txt

FILES

/usr/etc/venture/bin/venturelog

C:\Program Files\Xinet\Venture\Bin\venturelog.exe

242
 Syncs initiated using the Volume tab

Appendix B

Database synchronization

Syncs initiated using the When you make selections in the Volume GUI, WebNative Venture issues commands on the
Volume tab server. The commands depend both on the initial state of the volume and the options you
select in the GUI. Seven possibilities exist:

CASE 1: Enabling a volume for the first time (storing files only)

Literally this means:

• You’ve selected a Web Volume with the pop-up list.
• You’ve checked the Enabled Database button.
• You’ve clicked Submit.

WebNative Venture will run the following process:

userperms -sync -progress -del path_to_volume

This process can be seen in its entirety on UNIX systems. On Windows installations, it will
be seen as userperms.exe in the Task Manager. This is, in fact, true for the other six cases
too.

As a result:
• Files are read into the database.
• XMP and IPTC data are read into the database.
• Any file information about FlashNet archived files is read into the database.
• Previews of images, QuarkXPress files, InDesign files, and PDFs are not read into the
database.

For more information on the -del flag, refer to “Syncs: to -delnorm or not to -delnorm” on
page 248. The flag, which is analogous to using the -delnorm flag with syncvoltodb(1M),
will set everything to be offline. This is the most complete check of the file system. It is also
the only way to read in information about archived files.

If you are using FlashNet, globald needs to be running, because FlashNet indexes are con-
sulted. You'll see a blue bar for reading in file information and previews for live files, as
well as the file information for archived files. Then a gold progress bar starts as we read in
the previews for archives.

While the initial sync is running, the volume being enabled will be browseable as though it
were not Venture-enabled; that is to say, it will appear as a regular WebNative volume, with
all files being displayed as they exist on the file system and in FlashNet’s globald.sync file.
Once the sync is done, all files will be displayed as they exist in the database.

243
 Database synchronization

For more information on using FlashNet and WebNative Venture, see “Using WebNative
Venture and FlashNet” on page 207.

CASE 2: Enabling a volume for the first time (storing files and any combination of pre-
views/FPOs)

Literally this means:

• You’ve selected a volume from the pop-up list.
• You’ve checked Enabled Database, Store Small Web Preview, and/or Store Large Web
Preview and/or Store FPOs.
• You’ve clicked Submit.

The following process will be run:

userperms -sync -progress -del path_to_volume

This result will be:

• Files are read into the database
• XMP and IPTC data is read into the database.
• Previews/FPOs of images, QuarkXPress files, InDesign files and PDFs are stored in the
database.
• Any file/preview information about FlashNet archived files is read into the database.

CASE 3: Adding flags to store previews/FPOs on a volume that was already enabled

Literally this means:

• You’ve selected a volume from the pop-up list.
• The volume already had the Enable Database button checked.
• You have checked the Store Small Web Preview and/or Store Large Web Preview and/or
Store FPOs button(s).

You have clicked Submit.

The following process will be run:

userperms -sync -progress -del path_to_volume

This should result in the following behavior:

• Files are read into the database.
• XMP an IPTC data are read into the database.
• Previews/FPOs of images, QuarkXPress files, InDesign files and PDFs are stored in the
database
• Any preview information about FlashNet archived files is read into the database

Note that all the file information, XMP and IPTC data will be read into the database again.
This action will also read in all preview information about files archived with FlashNet.

244
Syncs initiated using the Volume tab

Therefore, if you are using FlashNet, be sure globald is running before you initiate this
action.

CASE 4: Re-submitting a volume without changing any flags

Literally this means:

• You’ve selected a volume from the pop-up list.
• You’ve clicked the Submit button.

The following process will be run:

userperms -sync -progress path_to_volume

This should result in the following behavior: a “quick” sync of the volume will be run.

Note the absence of the -del flag with the userperms process above. For more information
on syncs that do not use -del, see “Syncs: to -delnorm or not to -delnorm” on page 248.

CASE 5: Unchecking flags for storing one or more type of previews while leaving volume
enabled

Literally this means:

• You’ve selected a volume from the pop-up list.
• The volume already had the Enable Database plus one or more of the Store Preview/
FPO buttons checked.
• You have now deselect one or more of the Store Preview/FPO buttons.
• You’ve clicked the Submit button.

The following process will be run:

userperms -sync -progress path_to_volume

This should result in the following behavior:

• The volume will no longer store previews/FPOs of files added.
• File table entries remain the same.
• Previews of existing files will remain in the database.
• However, they will not be accessed when a user is browsing WebNative.

The current behavior of WebNative Venture is to continue to display previews stored in the
database for volumes that have had one or more preview flags disabled. This is considered a
bug, and we’re tracking it as Bug #3219. If you'd like to be notified when this is fixed, send
mail to help@xinet.com. For now, the work-around is to uncheck the flag and let the sync
run. Once the sync is done, run:
UNIX:/usr/etc/venture/bin/dbmgr -dbclean
Windows:C:\Progra~1\Xinet\Venture\bin\dbmgr -dbclean

This won't remove all previews, just ones for files that are in volumes set to not store those
types of previews. This will make the database smaller.

245
 Database synchronization

CASE 6: Unchecking Enable Database for a volume but leaving flags for storing one or
more type of previews checked

Literally this means:

• You’ve selected a volume from the pop-up list.
• The volume already has the Enable Database and one or more of the Store Preview/
FPO buttons checked.
• You’ve deselected only the Enable Database button.
• You’ve clicked the Submit button.

The following process will be run:

userperms [with no flags]

This should result in the following behavior:

• The volume no longer stores file or preview/FPO information about new files added.
• Existing files and preview/FPO information will be kept in the database, but won’t be
accessed by WebNative users.

This means that the size of the database does not decrease. The information is still stored.
Generally, this action is only done if you want to temporarily disable WebNative Venture on
a particular volume. When you re-enable it, less file/preview information has to be read in
again; thus the sync process will be much shorter. However, if your goal is to just disable
the database altogether for a brief time (and not just on one volume), it’s better to just stop
the database (using the nativeadmin GUI) and restart it later.

CASE 7: Unchecking flags for files and all stored previews — completely disabling the
database for a volume.

Literally this means:

• You’ve selected a volume from the pop-up list.
• The volume already had the Enable Database and one or more of the Store Preview/
FPO buttons checked.
• You’ve then deselected the Enable Database button and all the Store Preview/FPO but-
tons.
• You’ve clicked the Submit button.

The following process will be run:

userperms [with no flags]

This should result in the following behavior: See Case 6. It’s exactly the same.

Generally people use this option when they want to completely disable a volume and don’t
intend to re-enable it. To remove all trace of the files from this volume from the database,
do the following:

246
 Scheduled syncs

1. Find the volume id of the volume being removed. From the msyql client run select *
from volume. The volume id is the first column.
2. Use dbmgr(1M) to remove all files that were within that volume. For example, if the
volumeid were 3:
dbmgr -remove -vid 3

Scheduled syncs WebNative Venture can be told to periodically synchronize all database-enabled volumes to
the file system. This is done in the Database /Daemon page.

By default, a periodic sync is set to run once a week on Saturdays at midnight. You can
change that to be any time you like, running it as often as once a day. The times are
recorded in the following file:

UNIX:/var/adm/webnative/dblogd.conf
Windows:C:\Program Files\Xinet\WebNative\Admin\dblogd.conf

Periodic syncs are managed by the dblogd(1M) process. At the time of the sync, the running
dblogd(1M) process spawns a child. The child dblogd(1M) manages the synchronization
actions. For every event that requires an update to the database, the child dblogd(1) spawns
its own child. The “grandchild” process dies when the event has been given to mysqld. The
“child” process dies when the sync is complete. While a periodic sync is happening, you
will see a parent dblogd(1M), a child dblogd(1M), and possibly a grandchild dblogd(1M)
with a very short life span.

A periodic sync affects all enabled volumes; you can't specify volumes you don't want
synced.

Periodic syncs are similar to running a syncvoltodb path_to_volume; i.e,. a sync with
no flags. For more details on the -delnorm flag, see “Syncs: to -delnorm or not to -delnorm”
on page 248. In effect, this means that the sync done periodically is less thorough (but much
quicker) than a sync done with the -delnorm option.

Every periodic sync will cause the venture.log file to be moved to venture.log.old. A new
venture.log is not created immediately, but rather when the need to log something arises. In
other words, you may not see a venture.log file after a periodic sync.

The main purpose of running a periodic sync is to catch minor discrepancies between the
file system and the database that were not caught by dblogd(1) or listdir. Note that periodic
syncs will not catch every type of discrepancy. In those cases, a sync using one of the -del-
norm options is more appropriate.

Syncs done while All browsing in WebNative is handled by the listdir program. On a WebNative Venture
browsing enabled volume, listdir gets the list of items to display from the database. Additionally, list-
dir makes a check on the directory being browsed to verify that the contents displayed are
up to date in the database.

When listdir is run from a browser on a directory, it does two things:

247
 Database synchronization

1. Displays the items listed in the database as being within the directory.
2. Checks that the database matches the file system for this directory.

More precisely, the check in step 2 looks for a directory modification time discrepancy. Full
details of such discrepancies can be found in “Syncs: to -delnorm or not to -delnorm” on
page 248. If a discrepancy is found, listdir will run a sync on that directory and post an
event to the webdblog file. From there, dblogd will put the changes into the database. Note
that the sync does not descend through any subdirectories. Essentially, this is a sync without
a -delnorm.

Assuming that there is a discrepancy and that a sync is done on the directory, note that the
effects of the sync will not be seen until the browser is refreshed. That’s because step one
(the display) happens first. To see the changes made by step two (if any), one has to refresh
the browser.

When a directory is out of date, a comment is written to the venture.log file that looks like
this:

[Fri Apr 11 11:28:45]Warning: db was out of sync for [/export/Test-

ing/kiwi/Inner sanctum], resyncing...

One last note: listdir only checks from directory modification times, not file modification
times. By contrast, syncvoltodb(1M) checks for both directories’ and files’ modification
times. This results in slight differences in the “cover up” case that is detailed on page 250.

Syncs: to -delnorm or not The process responsible for synchronizing the database with the file system is called sync-
to -delnorm voltodb(1M). That process can be called by hand or by another program, such as userperms
or dblogd(1M). In all of these cases, the sync can be run with or without -delnorm option.

Important note:

Never use the -del flag with syncvoltodb(1M), for it has some bugs and can be destructive.
Always use -delnorm instead. Please read TechNote 152 for more details on this bug. How-
ever, as you have seen earlier, you can safely use a -del flag with userperms. In that
instance, -del performs with userperms exactly as -delnorm performs with syncvol-
todb(1M).

Default behavior

A sync happens on a directory-by-directory basis. The idea is to get the database’s informa-
tion on the folder’s contents to agree with what’s on the file system, and to do it as quickly
as possible. Roughly, here is the procedure for each directory:

1. WebNative Venture looks at a given folder on the file system, which by definition is
online, and asks:
What's the modification time?
2. For the moment, WebNative Venture stores that time.
3. Then WebNative Venture looks at the same folder in the database and asks:

248
Syncs: to -delnorm or not to -delnorm

Is the folder online?

4. If it’s listed as offline in the database, WebNative Venture will sync that directory and
any files it contains.
5. It it doesn't exist at all in the database, WebNative Venture will sync that directory.
6. Any subfolders inside are treated as a new folder (i.e., the questioning process starts
over.)
7. If the folder is listed as online, WebNative Venture won’t sync it (yet). Instead it will ask
a further question:
Is the modification time of the folder (according to the database) the same as the
modification time on the file system?
8. If the modification times are the same, then WebNative Venture doesn’t sync that folder
or the files it contains. If the modification times are different, WebNative Venture will
sync the folder and its files. Again, any subfolders are treated as new folders.

The idea here is to prevent synchronizing directories where nothing has changed (which is
very common.) Any change made to the files inside a folder (renaming, removing, adding)
will also update the modification time of the folder itself. Therefore, it’s safe to assume that
a folder whose modification time is identical to that in the database doesn't contain files that
have been changed since the last sync/update of the database.

In sum, WebNative Venture only synchronizes the contents of a folder if there is a disagree-
ment between the file system and the database about the folder’s online status or its modifi-
cation time.

There is also one exception to note: when a file has been modified by an application other
than Photoshop, the directory’s modification time is not updated. That sort of change will
escape the method described above. Therefore, WebNative Venture also checks file modifi-
cation dates in all directories. Upon finding a file modification discrepancy, WebNative
Venture will update that file.

Using -delnorm

The -delnorm flag means:

Set all files as offline.

Setting all files as offline ensures that the syncvoltodb(1M) will synchronize every file and
folder on the file system without exception. That’s because the answer to Is the folder
online? will always be No — and therefore, WebNative Venture will synchronize the entire
file system.

There should be nothing different between the database and the file system after a
-delnorm sync.

A -delnorm sync will consult globald for information about any archived files within the
WebNative Venture enabled volume.

249
 Database synchronization

Not using -delnorm

A sync run without a -del or -delnorm simply uses the procedure outlined in the “Default
behavior” on page 248.

This type of sync is designed to catch changes made to the file system that evaded
dblogd(1M), and to do it quickly. It only consults globald when there is a directory modifi-
cation discrepancy.

Typical operations that do not use a -delnorm include:

• Resubmitting a volume in the Volumes tab without changing any of the options.
• Scheduled synchronizations
• Synchronizations run by listdir on the directory being displayed.

Syncs run without a -delnorm flag have one big flaw, known as the “cover-up” case. Nor-
mally, any change made to the file system (via SMB, NFS, or UNIX) will cause a modifica-
tion time discrepancy for the folder, thus setting up this directory to be synchronized when
a sync is run. However, the modification time discrepancy can be covered up. Consider this
scenario:

TIME RECORDED IN:

Activity File system Database

Directory modification time 2 PM 2 PM
1. File added via ksd(1M)
Directory modification time 3 PM 3 PM
2. File added via UNIX at 4 PM
Directory modification time 4 PM 3 PM
At this point, a sync (without a -del) will notice the modification time
discrepancy and sync this directory.
3. File added via ksd(1M) 5 PM 5 PM
At this point, a sync (without a -del) will not find a modification time discrepancy
and will not sync this directory.

So whatever files where added at 4 PM via UNIX or SMB will not be added to the database
when the sync happens. The only option is to run a syncvoltodb -delnorm on that direc-
tory (or a directory above it).

As you can see, this adds an element of chance as to whether files will be caught by the sync
or not. TechNote 161: Keeping SMB/NFS Volumes in Sync summarizes your options for
handling a situation like this.

250
 Limited warranty on media and manual

Appendix C

Credits and trademarks

Adobe Photoshop, Adobe InDesign, and Adobe Illustrator are registered trademarks of Adobe Systems, Inc. Macintosh, Apple, and AppleShare are
trademarks of Apple Computer, Inc. Microsoft and Windows are registered trademarks of the Microsoft Corporation. Quark, QuarkXPress and Quark
XTensions are trademarks of Quark, Inc. which have been registered in the U.S. Patent and Trademark Office and in many other countries. Silicon
Graphics is a registered trademark and IRIX is a trademark of Silicon Graphics, Inc. NFS, SunOS, and Solaris are trademarks of Sun Microsystems, Inc..
UNIX is a registered trademark of X/Open Ltd. All other product name brands or trademarks are owned by their respective companies.

FullPress, WebNative, the Xinet server design, and Xinet are registered trademarks of XINET, Inc in the U.S. Patent and Trademark Office. FullPress,
WebNative and Xinet are also registered trademarks in many other countries.

© Copyright 1989, 2007 by XINET Inc. This manual and the software described in it are copyrighted with all rights reserved. Neither the guide nor
software may be copied in whole or in part without the written consent of XINET Inc., except in the normal use of the software by the owner to make
working copies for the purchaser’s own use as described in this manual.

Tag Image File Format Library © Copyright 1988,1989, 1990, 1991, 1992, 1993, 1994 Sam Leffler. © Copyright 1991, 1992, 1993, 1994 Silicon
Graphics, Inc. Permission to use, copy, modify, distribute and sell the Tag Image File Format Library documentation for any purpose is hereby granted
without fee, provided that (i) the above copyright notices and this permission notice appear in all copies of the software and related documentation, and
(ii) the names of Sam Leffler and Silicon Graphics may not be used in any advertising or publicity relating to the software without the specific, prior written
permission of Sam Leffler and Silicon Graphics.

This software is based in part on the work of the Independent JPEG Group.

Portions of the software, including ndbm(3), © Copyright 1983 Regents of the University of California. All rights reserved. The Berkeley software License
Agreement specifies the terms and conditions for redistribution.

Portions of the software © Copyright 2000 Artefex Software Inc. All rights reserved.
Portions of the software © Copyright 2000 Aladdin Enterprises. All rights reserved.

The curl and libcurl portions of this software © Copyright 2000, Daniel Stenberg, daniel@haxx.se. All rights reserved. Permission is hereby granted, free
of charge, to any person obtaining a copy of curl and libcurl and associated documentation files (the “Software”), to deal in the Software without
restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, and/or sell copies of the Software, and to permit persons
to whom the Software is furnished to do so, in all copies of the Software and that both the above copyright notice(s) and this permission notice appear in
supporting documentation.

Portions of this software © Copyright 2000, MySQL AB and MySQL, Finland AB.

XMP portions © Copyright 2004 Adobe Systems Incorporated and others. All rights reserved. The original version of this source code may be found at
http://adobe.com.

Limited warranty on XINET warrants that the manual accompanying this software product and the physical media on which the software is furnished are free from defects in
their production. XINET will replace said media and/or manuals, if defective, if they are returned to XINET postage prepaid, along with proof of purchase.
media and manual The warranty and remedies set forth above are exclusive and in lieu of all others, oral or written, express or implied. No XINET dealer, agent, or employee
is authorized to make any modification, extension, or addition to this warranty. This warranty gives you specific legal rights, and you may have additional
rights which may vary from state to state.

Disclaimers of warranty Even though XINET Inc. has tested the software and reviewed the documentation, XINET Inc. makes no warranty or representation, either express or
implied, with respect to this software, its quality, performance, merchantability, or fitness for a particular purpose, with the exception of the limited
warranty on media and manual expressed above. As a result, this software is sold as is, and you the purchaser are assuming the entire risk as to its quality
and performance. In no event will XINET Inc. be liable for direct, indirect, special, incidental, or consequential damages resulting from any defect in the
software or its documentation. In particular, XINET Inc. shall have no liability for any damage to programs or data used with XINET Inc. products,
including the costs of recovering such programs or data. The warranty and remedies set forth above are exclusive and in lieu of all others, oral or written,
express or implied.

251
 Xinet software license

Xinet software license

Our software license is included here so you can read it before using the software. DO NOT install the software from this CD until you have carefully read
this Agreement. BY INSTALLING THIS SOFTWARE YOU ACCEPT ALL THE TERMS AND CONDITIONS OF THIS AGREEMENT. If you do not
agree with the terms and conditions of this Agreement, return the software package within a reasonable time to your supplier for a full refund.

In return for acquiring a license to use the software and related documentation (“Software”), you agree to the following terms and conditions:

1. Grant of License. Xinet grants to you a nonexclusive, nontransferable license to use the Software on one computer system and to make one copy of the
software solely for backup purposes. You must place the same copyright and other proprietary rights notices on any copy of the Software as appears
on the original. You must not transfer, sell, assign, rent or distribute any copies of the Software to others. Xinet reserves all rights not expressly granted
to you.

2. Proprietary Rights. As a licensee, you own the media on which the Software is originally recorded. The Software is copyrighted by and proprietary to
Xinet and its suppliers. Xinet and its suppliers retain title and ownership of all copies of the Software. The nonexclusive license set forth in this
Agreement is not a sale of the Software or any copy. You agree that you will not assign, sublicense, transfer, pledge, lease or share your rights under
this Agreement and agree to take all reasonable steps to prevent unauthorized use. You agree you may not reverse assemble, reverse compile, or
otherwise translate the software.

3. No Other Rights. Except as stated above, this Agreement does not grant you any rights to patents, copyrights, trade secrets, trade names, trademarks
(whether registered or unregistered), or any other rights, franchises, or license in respect of the Software. You MAY NOT MODIFY TRANSLATE,
DISASSEMBLE, OR DECOMPILE THE SOFTWARE OR ANY COPY, IN WHOLE OR IN PART.

4. Term. The license is effective until terminated. You may terminate the license at any time by destroying the Software (including the related
documentation) together with all copies or modifications in any form. Xinet will have the right to terminate your license immediately if you fail to
comply with any term or condition of the Agreement. Upon any termination you must destroy the Software together with all copies or modifications
in any form.

5. LIMITED WARRANTY

Xinet warrants to you that the Software will perform substantially in accordance with the user’s manual for a period of thirty (30) days after delivery
to you (“Warranty Period”).

If the Software fails to comply with this limited warranty, Xinet will at its option and at no cost to you, correct errors you discover which you report
during the Warranty Period, or replace the Software, or refund the license fee paid for the Software provided you return the Software.

XINET AND ITS SUPPLIERS DO NOT AND CANNOT WARRANT THE PERFORMANCE OR RESULTS YOU MAY OBTAIN BY USING THE
SOFTWARE OR DOCUMENTATION. THE FOREGOING STATES THE SOLE AND EXCLUSIVE REMEDIES XINET WILL PROVIDE FOR
BREACH OF WARRANTY. YOU UNDERSTAND THAT, EXCEPT FOR THE FOREGOING 30-DAY LIMITED WARRANTY, XINET AND ITS
SUPPLIERS MAKE NO WARRANTIES EXPRESS OR IMPLIED, AS TO PERFORMANCE, OR NON-INFRINGEMENT OF THIRD PARTY
RIGHTS, MERCHANTABILITY, OR FITNESS FOR ANY PARTICULAR PURPOSE.

Some states do not allow the exclusion of implied warranties or limitations on how long an implied warranty may last, so the above limitations may
not apply to you. This warranty gives you specific legal rights and you may also have other rights which vary from state to state.

a. LIMIT OF LIABILITY.
XINET’S LIABILITY IN ANY EVENT IS LIMITED TO THE AMOUNT OF LICENSE AND SUPPORT FEES PAID BY THE LICENSEE. IN
NO EVENT WILL XINET OR ITS SUPPLIER BE LIABLE TO YOU FOR ANY SPECIAL DAMAGES, INCLUDING ANY LOST PROFITS,
LOST SAVINGS OR OTHER INCIDENTAL OR CONSEQUENTIAL DAMAGES, EVEN IF XINET OR ANY XINET REPRESENTATIVE
HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES, OR FOR ANY CLAIM BY ANY OTHER PARTY.

Some states do not allow the exclusion or limitation of incidental or consequential damages, so the above limitation or exclusion may not apply to
you.

b. Export.
You acknowledge that the laws and regulations of the United States restrict the export and re-export of the Software. You agree that you will not
export or re-export the Software or media in any form without the appropriate United States and foreign government approval.

c. Choice of Law. This Agreement will be governed by the laws of the State of California as applied to transactions taking place wholly within
California between California residents.

d. U.S. Government Restricted Rights Legend. The Software (including the documentation) is provided with RESTRICTED RIGHTS. Use,
duplication, or disclosure by the Government is subject to restrictions as set forth in subparagraph (c)(l)(ii) of the Rights in Technical Data and
Computer Software clause at 252.2277013.

e. Integration. You acknowledge that you have read this Agreement, understand it, and that by installing the software you agree to be bound by its
terms and conditions. You further agree that it is the complete and exclusive statement of the agreement between Xinet and you which supersedes
any proposal or prior agreement, oral or written, and any other communications between Xinet and you relating to the subject matter of this
Agreement. No variation of the terms of the Agreement or any different terms will be enforceable against Xinet unless Xinet gives its express
consent, including an express waiver of the terms of this Agreement, in writing signed by an officer of Xinet.

252
Gültig nur für Appendix D
Produkte, die in
Deutschland Endbenutzer-Lizenzvertrag für XINET-Software
lizensiert wurden.
Wichtig bitte sorgfältig lesen: Dieser XINET-Endbenutzer-Lizenzvertrag ist ein rechtsgültiger Vertrag zwischen Ihnen (entweder als natürliche oder
juristischer Person) und der XINET für ein XINET-Software-Produkt. Das Software-Produkt umfaßt Computer-Software sowie möglicherweise
This applies only dazugehörige Medien, gedruckte Materialien und „online“ oder elektronische Dokumentation („Software-Produkt“). Indem Sie das Software-Produkt
installieren, kopieren oder anderweitig verwenden, erklären Sie sich einverstanden, durch die Bestimmungen dieses Lizenzvertrages gebunden zu sein.
to products licensed Falls Sie diesen Bestimmungen nicht zustimmen, sind Sie nicht berechtigt, das Software-Produkt zu installieren oder zu verwenden; Sie können es jedoch
gegen Rückerstattung des Kaufpreises an den Händler zurückgeben, von dem Sie es erworben haben.
in Germany.
Das Software-Produkt wird sowohl durch Urheberrechtsgesetze und internationale Urheberrechtsverträge geschützt, als auch durch andere Gesetze und
Vereinbarungen über geistiges Eigentum. Das Software-Produkt wird lizenziert, nicht verkauft.

1. Lizenzeinräumung. XINET räumt Ihnen unter der Einschränkung der Regelung in Ziff. 2.f) dieses Vertrages das zeitlich unbegrenzte, nicht
ausschließliche und nicht übertragbare Recht ein, das Software-Produkt im vertragsgemäßen Umfang zu nutzen. Sie sind berechtigt, eine Kopie des
Software-Produkts auf einem einzelnen Computer zu installieren und zu verwenden. Ferner dürfen Sie eine Sicherungskopie anfertigen.

2. Weitere Rechte und Einschränkungen

a) Nicht zum Weiterverkauf bestimmte Software. Falls Ihnen das Software-Produkt als Demonstrationsmaterial überlassen wird, sind Sie
ungeachtet anderer Abschnitte dieses Lizenzvertrages, nicht berechtigt, das Software-Produkt weiterzuverkaufen oder auf andere Weise gegen
einen Gegenwert oder unentgeltlich zu übertragen. Sollten Sie die Hardware auf welcher die Software installiert ist veräußern, sind Sie verpflichtet,
sämtliche Kopien des Softwareprodukts zu zerstören bzw. an XINET zurückzugeben.

b) Beschränkung im Hinblick auf Zurückentwicklung (Reverse Engineering), Dekompilierung und Disassemblierung. Sie sind nicht
berechtigt, das Software-Produkt zurückzuentwickeln (Reverse Engineering), zu dekompilieren oder zu disassemblieren, es sei denn und nur
insoweit wie das anwendbare Recht, ungeachtet dieser Beschränkung, dieses ausdrücklich gestattet.

c) Trennung von Komponenten. Das Software-Produkt wird als einzelnes Produkt lizenziert. Sie sind nicht berechtigt, dessen Komponenten für die
Verwertung auf mehr als einem Computer zu trennen.

d) Vermietung. Sie sind nicht berechtigt, das Software-Produkt zu vermieten, zu verleasen oder zu verleihen.

e) Serviceleistungen. XINET bietet Ihnen möglicherweise Serviceleistungen in Verbindung mit dem Software-Produkt („Serviceleistungen“). Die
Serviceleistungen können entsprechend den XINET-Bestimmungen und –Programmen, die im Benutzerhandbuch, der „Online“-Dokumentation
und/oder anderen von XINET zur Verfügung gestellten Materialien beschrieben sind, genutzt werden. Jeder ergänzende Software-Code, der Ihnen
als Teil der Serviceleistungen zur Verfügung gestellt wird, wird als Bestandteil des Software-Produkts betrachtet und unterliegt den Bestimmungen
und Bedingungen dieses Lizenzvertrages. XINET ist berechtigt, die technischen Daten, die Sie XINET als Teil der Serviceleistungen zur
Verfügung stellen, für geschäftliche Zwecke, einschließlich Produktunterstützung und entwicklung, zu verwenden. XINET verpflichtet sich,
solche technische Daten ausschließlich anonym im Sinne des Datenschutzes zu verwenden.

f) Kündigung. Unbeschadet sonstiger Rechte ist XINET berechtigt, diesen Lizenzvertrag zu kündigen, sofern Sie gegen die Bestimmungen und
Bedingungen dieses Lizenzvertrages verstoßen. In einem solchen Fall sind Sie verpflichtet, sämtliche Kopien des Software-Produkts und alle seine
Komponenten zu vernichten. Durch Zerstörung der Software einschließlich seiner Kopie und damit verbundenen Dokumentation kündigen Sie
selbst den Lizenzvertrag.

3. Urheberrecht. Eigentum und Urheberrecht an dem Software-Produkt (einschließlich, aber nicht beschränkt auf Bilder, Fotografien, Animationen,
Video, Audio, Musik, Text und „Applets“, die in dem Software-Produkt enthalten sind), den gedruckten Begleitmaterialien und jeder Kopie des
Software-Produkts liegen bei XINET. Das Software-Produkt ist durch Urheberrechtsgesetze und internationale Urheberrechtsbestimmungen
geschützt. Aus diesem Grund sind Sie verpflichtet, das Software-Produkt wie jedes andere durch das Urheberrecht geschützte Material zu behandeln,
mit der Ausnahme, daß Sie berechtigt sind, das Software-Produkt auf einem einzelnen Computer zu installieren, vorausgesetzt, Sie bewahren das
Original ausschließlich für Sicherungs- und Archivierungszwecke auf und schützen es vor unerlaubter Offenbarung. Sie sind nicht berechtigt, das das
Software-Produkt begleitende gedruckte Material zu vervielfältigen.

4. Gewährleistungen

a) XINET und ihre Vertragshändler weisen darauf hin, daß es nicht möglich ist, Software so zu entwickeln, daß sie für alle Anwendungsbedingungen
fehlerfrei ist. Dafür übernimmt XINET für einen Zeitraum von 30 Tagen ab Auslieferung an Sie die Garantie, daß das Software-Produkt im
wesentlichen gem. den beiliegenden bedruckten Materialien arbeitet.

b) Darüber hinaus stehen XINET und ihre Vertragshändler für Mängel, die bei der Übergabe des Software-Produkts vorhanden sind, während einer
Gewährleistungsfrist von 6 Monaten gem. folgenden Regeln ein.

c) Als Mängel im Sinn der Ziffer 4.b) gelten Abweichungen des Software-Produkts von den beiliegenden bedruckten Materialien, soweit diese
Abweichungen die Tauglichkeit des Software-Produkts beeinträchtigen. Eine unerhebliche Minderung der Brauchbarkeit bleibt außer Betracht.

d) Erweist sich das Software-Produkt als nicht brauchbar oder fehlerhaft, werden XINET und ihre Vertragshändler diese Mängel binnen
angemessener Frist beheben. Gelingt ein derartiger Nachbesserungsversuch nicht innerhalb angemessener Frist und schlägt er auch innerhalb einer
weiteren, von Ihnen angemessen gesetzten Frist fehl, und stellen XINET und ihre Vertragshändler keine Umgehungslösung gem. Ziff. 4.e) zur
Verfügung, so stehen Ihnen die gesetzlichen Gewährleistungsrechte zu. Sie können dann den Vergütungsanspruch herabsetzen (mindern) oder den
Vertrag rückgängig machen (wandeln).

e) XINET und ihre Vertragshändler sind berechtigt, einen eventuell auftretenden Fehler zu umgehen, wenn der Fehler selbst nur durch
unverhältnissemäßigen Aufwand zu beseitigen ist und dadurch der Einsatz des Software-Produkts nicht erheblich leidet.

f) XINET und ihre Vertragshändler haften nicht, wenn der Fehler unseres Produkts auf einem Unfall, Mißbrauch oder fehlerhaften Anwendung
beruht.

g) XINET und ihre Vertragshändler haften nicht für Folgeschäden und im übrigen nur nach den Bestimmungen der Ziff. 5. Weitergehende
Gewährleistungsansprüche sind ausgeschlossen. Darüber hinausgehende Leistungen bieten XINET und ihre Vertragshändler im Zusammenhang
mit Support-Leistungen an, soweit nicht ein zusätzlicher Vertrag über Support-Leistungen abgeschlossen wurde.

253
 : Endbenutzer-Lizenzvertrag für XINET-Software

5. Haftung

a) XINET und ihre Vertragshändler haften für anfängliches Unvermögen, Verzug und Unmöglichkeit auf solche Schäden begrenzt, die aufgrund der
vertraglichen Verwendung typisch und vorhersehbar sind. In einem derartigen Fall ist die Haftung auf den Betrag, den Sie für das Software-Produkt
bezahlt haben, begrenzt.

b) Im übrigen haften XINET und ihre Vertragshändler unbeschränkt nur für Schäden, die durch Vorsatz oder grobe Fahrlässigkeit ihrer gesetzlichen
Vertreter und/oder ihrer leitenden Angestellten verursacht wurden. Für Schäden, die durch ein Verschulden sonstiger Mitarbeiter und
Erfüllungsgehilfen verursacht worden sind, haften XINET und ihre Vertragshändler nur im Umfang der Haftung nach Ziff. 5.a).

c) Für leichte Fahrlässigkeit haften XINET und ihre Vertragshändler nur, sofern eine Pflicht verletzt wird, deren Einhaltung für die Erreichung des
Vertragszwecks von besonderer Bedeutung ist (Kardinalpflicht). Bei Verletzung einer Kardinalpflicht gilt Ziff. 5.a) entsprechend.

d) Den besonderen Risiken der Überlassung des Software-Produkts entsprechend wird die Haftung für Folgeschäden und entgangenen Gewinn
ausgeschlossen, soweit ein derartiger Schaden nicht auf Rechtsmängel, das Fehlen zugesicherter Eigenschaften, Vorsatz oder grobe Fahrlässigkeit
der gesetzlichen Vertreter oder leitenden Angestellten zurückzuführen ist. XINET und ihre Vertragshändler haften nur für die Wiederherstellung
von Daten, soweit Sie regelmäßig und gefahr-entsprechend Sicherungskopien angefertigt und sichergestellt haben, daß die Daten aus diesen
Sicherungskopien mit vertretbaren Aufwand rekonstruiert werden können. Eine darüber hinausgehende Haftung für Datenverluste ist
ausgeschlossen.

e) Die vorstehenden Regelungen gelten auch zugunsten der Mitarbeiter und Erfüllungsgehilfen von XINET und ihren Vertragshändlern. Die
Haftungsbeschränkungen gelten nicht für Ansprüche nach dem Produkthaftungsgesetz.

6. Anwendbares Recht. Wenn Sie unser Produkt in Deutschland gekauft haben, unterliegt der Lizenzvertrag deutschem Recht.

254
 Index

Index troubleshooting, 174

Action Run window, 6
Actions and Triggers, 137
A Actions directory, 169
active collection, 50, 51
access
Active Path, 137
limiting, 38
adding, 142
Access Control List, 36, 37
Active Paths, 164
Access Control List pop-up menu, 92 not copying, 162
access logs, 55 active selection, 50
ACID, 78 Add and Edit button, 111, 113, 116, 118, 121
ACL, 92 Add Current Values button, 112, 116, 119
localhost ONLY, 92
Add Data Field pop-up list, 129
ACL statement
Add Group button, 53
example, 74
Add Index button, 92
Action, 137
adding a new setting, 161 Add Permission Set button, 132
adding a setting to, 149 Add User button, 36
administrative settings files, 172 Add Volume button, 38, 43
archive, 150 Administer Baskets, 49
autosaving, 149 administrative privilege, 33
.buildconfig files, 171
Adobe CS, 181
compare, 150
configuration files, 170 Alias PIX, 1
copy, 151 Allow uploads, 42
creating, 137 Annotator Plug-in, 23
curl, 154 Annotator Plug-in for InDesign, 23
email, 138, 151 Annotator XT, 23
executables, 169
Annotator XT for QuarkXPress, 23
general rules for modifying, 173
GUI files, 171 Apache, 33, 71
list of, 138 IRIX, 28
list of those installed on system, 160 Linux, 28
logs, 165 Mac OS X, 28
move, 153 mod-proxy module, 73
movetree, 82, 155 not using the OS-specific installation, 27
new settings for, 161 Solaris, 27
possibilities upon completion, 148 Windows, 28
print, 154 Apache_SSL, 75
remove, 154 applet, 45
setdatafield, 154 appletemail style, 45
setting, 137 archive, 1, 42
summary window, 149 ensuring properly displayed, 208
troubleshooting, 152 importing information about, 197
action, 46 number of folders, 95
admin, 46 restoration, 1
Action Rule Set restoration request, 49
administration, 167 resyncing, 209
logging information, 165 the number of Items, 94

255
Index

to disk, 81, 155 boolean

archive Action, 150 definition, 120
archived files, 89 boolean field, 108, 120
archivefile, 209 buttons style, 45
archivemedia table, 208
archivepath table, 209
C
archive to disk
grooming archives, 83 Cascading Style Sheets (CSS), 46
strategy, 81
CD ROM drive
using movetree Action, 156
local, 7
Asset Fulfillment Admin, 49 remote, 6, 7
Asset Fulfillment Request, 49 certificate
asset reference field, 199 creating, 75
asterisk, 108 Change Keyword, 40
at_log, 97 changeuser, 45
at_log, 219 check-basket, 50
at_log.wn, 97 classichouse, 45
authentication, 33, 71 classic style, 44
increasing security, 71 Clear collection function, 51
Kerberos and LDAP, 71
clipping path
mod_ldap, 71
preserving in Large Web Preview, 18
collection, 50
B clearing, 51
loading, 51
backupfile table, 209 saving, 51
backup location, 98 collections window, 50
backuppath table, 209 command and control information, 70
backups, 97 comments, 40
full and quick, 98 compare Action, 150
restoring, 99 compressed files, 42
scheduling, 98 Configuration
BARCO, 1 plugins, 48
Base Directory, 91 Configuration Creation Wizard, 23
Basic Authentication, 71 Configuration file for Uploader, 136
basket, 50 configure.apache, 27
default, 50 Contex CT, 1
existing collection, 51 Continue upon failure, 149
naming, 51
conventions
saving, 51
typographical, 2
saving and loading, 50
Copy, 36
basketadmin, 51
copy Action, 151, 169
Basket API, 50
copy Action configuration file, 170
Batch Apply, 49
copy Actions tandard arguments, 170
batch downloading, 42
Copypath, 155
bigdir, 45
Copy Permset pop-up list, 132
BIGINT, 113

256
 Index

Copy Template pop-up list, 128 Database tab, 90

Copy user pop-up menu, 36 Data Directory, 91
Create and Edit Template button, 129 data field, 95, 108, 117, 163
Crosfield Studio 9000, 1 Action automatically changing value of, 154
Cumulus adding, 109
importing from, 198 adding a boolean field, 120
metadata, 199 adding a date field, 117
previews, 199 adding a floating point field, 114
adding an integer field, 112
custom-icon preview, 39
adding a text field, 109
custom image order, 1, 42 adding custom XMP field, 181
customization, 43 adding to a template, 129
customize installation button, 7 avoiding erroneous information in, 133
Custom Pop-up Values list, 116, 119 built in set, 122
deleting, 121
deleting a set, 124
D descriptions, 109
display type, 117
daemon editing set, 123
communicating with fpod(1), 219 establishing pop-up list, 111
configuring, 96 establishing sets, 122
dblogd, 95 IntMap, 180
FPO, 95 locked set, 180
mysqld, 95 modifying or editing, 120
DALiM CT and LW, 1 names, 108
predefined and locked, 129
data
preprogrammed, 108
exported, 189
read only, 129
importing, 189
sets, 180
moving to the WebNative Venture server, 189
showing those in current use, 134
when actual files aren’t moved to server, 189
types, 108
database, 95 user-defined set, 180
accessible at all, 215 user set, 122
backup underway?, 215
Data Fields tab, 107
daemons, 95
data directory, 93 Dates, 40
enabling, 88 Date Trigger, 147, 168
load balancing, 95 dblogd
options for volumes, 88 dblogd, 87, 95, 97, 125, 174, 179, 194
previews stored in, 88 dblogd(1M), 60, 105, 213, 214, 247
processing, 95 file added behind its back, 216
records, 94 not running, 213
slow responding to queries, 217 writing XMP, 179
starting and stopping, 92
dblogd.conf, 105, 106
status report, 217
suspending activity, 97 dbmgr(1M), 92r, 215, 247
tables, increasing storage capacity, 89 dbmgr.exe, 215
turning off briefly, 216 DCS 1.0 and 2.0, 1
users, 94 Decimals box, 115
verification, 96 default basket window, 50
Database Management System, 95 default style, 46

257
Index

Delete Group, 53 dtrebuild, 14

Delete or Delete all buttons, 114 Dynamic and/or Private Ports, 70
Delete Template button, 128
Delete User, 53
E
delnorm, 243, 244, 248, 249
Description type-in box, 110, 113, 115 Eclipse TILE, 1
Destination field, 151 Edit Data Fields, 40
Detailed History button, 40, 106 Edit Data Fields button, 121
detailed style, 45 Edit Permission Sets button, 134
digital signature, 75 Edit Rules window, 140
directory services, 29 Edit Template button, 128, 130
Disable all downloads, 43 email, 45
disable.venture, 102 email Action, 151, 171
dismiss button, 38, 53 changing who mail come from, 153
dist directory, 7 keywords, 152
DMZ, 74 email reports
DNS, 69 enabling for uploads, 23
DNS server, 74 email to the site administrator, 49
document preview encryption, 75
problem with, 218 encryption key, 75
domain name Enter New License, 5
fully qualified, 78 EPS, 1
Don’t make WEB previews for..., 32 EskoFot/EskoScan, 1
Downlad JPEGs, 49 Exit and Notify upon failure, 149
download Exit upon failure, 149
basket, 42 export command, 201
batch image order, 49
export executable, 201
disabling, 43
icons used for, 46 export file, 190
log file, 57 export text language, 201
simple, 44
StuffIt archive of FPOs, 49
StuffIt archive of images, 49 F
versions, 40
Download FPOs, 43 FastTrack, 33
Download GIFs, 49 Field Cols box, 110
Download High Res, 43 Field Rows box, 110
Download Hi-res images and files, 43 fields
customizing which users see, 135
Download Non-Image, 43
Field Size type-in box, 113, 115
Download only files for which FPOs aren’t being made,
43 Field Type, 133
download permissions, 42 Field Type pop-up list, 110, 112, 115, 117, 120
Download without Clipping Paths, 49 File Event Trigger, 147, 168
drag and drop, 17, 19 file management, 42
server configuration for, 17 File Manager, 5
dtool_env configuration file, 207 log for, 59

258
 Index

file system FullText index, 91, 92

doesn’t match database, 213 creation underway?, 215
full, 97
file transaction logging, 92
file type, 1 G
Firefox
GIF previews, 32
WebNative Helper for, 17
globald, 208, 214, 243
firewall, 72, 74
logs, 78 globald.sync, 208
FlashNet, 150 global.js, 48
confirming that it is installed, 208 group
indices read, 207 primary, 36
storing previews of archived images, 207 groups, 36, 53, 94
FlashWeb, 150
flat file, 201
H
flexible, 45
floating point hardware requirements, 2
definition, 114
help button, 33
floating point field, 108, 114
honey pots, 78
flush table, 217
housechangeuser, 45
folder, 38
house style, 44
folder online, 249
HSM Sync option, 89
formandemail, 45
httpd, 70
For Template pop-up list, 132, 134
httpd.conf file, 72, 73
FPO, 94
daemon, 95
downloading, 43 I
for PDF files, 43
for “Vector” EPS files, 43 icon, 46
web, 32
icon view, 39
fpod(1
IIS, 11
fpod(1M), 219
image
logging from, 218
compression, 42
fpod_vlogfile, 218 time when last accessed, 40
fpod.conf, 218 image resolution (always) limited to, 32
FPO Info, 40 import, 189
ftpd, 70 import command
FullPress constructing, 190
volumes which support WebNative, 31 importing data, 189
FullPress AppleShare Server Setup, 38 import program, 189
FullPress Versioning, 40 InDesign
fullrestore.sql, 99 linked files, 41
FullText, 124 previews, 17
fulltext data field, 109 index
FullText Index enabling FullText, 125
preserving, 5 enabling regular, 124

259
Index

FullText, 92, 124 limit the pixel dimensions for WEB FPOs, 32
regular, 124 linked files viewer, 41
removing, 92 Linksys Instant Broadband NAT, 74
indexed data field, 109 Linux, 28
indexed searching, 124 AppleTalk support, 15
indexing site, 73 list, 45
installwebnative icon, 5 load balancing, 95
integer field, 108, 112 Localized Name Variable, 152
Integer Type pop-up list, 113 local.js, 48, 182
Interactive PDF, 23, 41 Locked button, 129
IntMap, 180 log, 55
invoice, 55 MySQL startup and shutdown, 219
IPTC, 108, 179, 185, 243, 244 log file
IRIX, 2, 7 for previews in database, 60
ISO Latin character set, 108 Logs GUI, 55
item with Data Fields, 95 Logs tab, 56
Long View, 39, 40

J
M
JFIF, 1
JPEG, 1 Mac OS X, 2, 8
mailto.exe, 12
Make GIF-format WEB previews of masked or clipped
K images, 32
Manager.log, 135
key frame
Manager.prefs, 135
daemon that writes to database, 220
MaskCutter, 1
keyword, 124
Max Digits type-in box, 115
keyword1, 124
Max Length box, 110
keyword1 table, 125, 187
Max Length variable, 125
KeywordCache file, 136
memory and thread Limits, 91
keywordid, 186, 187
Memory Buffer Size, 91
keywords
batch apply, 49 memory usage
heavy, 91
keyword table, 186
metadata, 85
Kodak PhotoDisk, 1
adding to multiple files at once, 49
entering in a consistent manner, 112
exported, 201
L
exporting, 190
how stored in the database, 186
lang.keywordid, 124
Microsoft Office
large web preview, 89
daemon that writes previews of, 220
generated on-the-fly, 18
document previews, 2
LDAP, 71 previews of documents, 20
libXm.so.3, 16 Microsoft Office files
license string, 5 multipage previews of, 89

260
 Index

mkfpo(1), 60 No long view, 39

mod_ldap, 71 No short view, 39
mod_ssl, 75, 77
modification time, 248
O
Modify button, 31
Modify Entry dialog, 52 officesync, 220
modify user’s volume access, 52 log for, 218
mod-proxy module, 73 On Failure, 137
mount point, 6 On Failure email settings, 149
move Action, 153 openoffice2.1, 89
Movepath, 155 OpenSSL, 75
movetree Action, 82, 155 open table, 217
movsync Open Windows, 6
log for, 218 options/arguments window, 6
movysnc, 220 Options for making WEB FPOs, 32
MS World Wide Web Publishing Service, 11 Overwrite/Append/Fail drop-down menu, 138
mview, 46, 219 Overwrite/Append/Fail option, 151, 153
MySQL, 86, 90, 95, 214 owner, 38
starting and stopping, 92
web site, 218
mysqld, 95, 213 P
memory buffer size, 91
what it’s processing now, 216 packet, 71
packet-analyzing intrusion-detection system (IDS), 78
page
N
drawn from database or file system?, 214
NAA, 95 password, 36, 55
template, 128 change, 37
policy, 71
Name type-in box, 110, 112, 115
user can change, 45
nativeadmin, 33, 55
PDF, 1
changing password, 34
daemon that writes multipage previews, 220
GUI, 46
interactive links within, 23
NAT/Virtual server, 72 linked files, 41
Network Address Translation (NAT), 74 multi-page previews, 89
New Data Field button, 110, 112, 115, 117, 120 opening in a WebNative browser, 23
New group button, 53 pdfsync, 220
New Rule Set subtab, 162 log for, 218
New Setting subpanel, 161 permissions, 38
New Setting window, 138 download, 42
volume default settings, 38
New Template button, 128
Permission Set pop-up list, 134
new user
giving access to volumes, 35 permission sets, 131
assigning to users, 135
New User button, 35
built-in fields, 134
New Value field, 111, 116 copying, 132
New Volume button, 31 editing or deleting, 134

261
Index

establishing, 132 Q
making information visible, 132
searchable, 132 QuarkXPress
type-in boxes vs. pop-up lists, 133 linked files, 41
Permission Set type-in box, 132 previews, 17
Photoshop, 185 query, 90
Photoshop Native, 1 slow, 91, 217
physical media, 49 quickrestore.sql, 99
pixel dimensions quick start, 4
limiting for WEB FPOs, 32
pkgadd(1M), 6
R
plugin, 49, 50
save collection, 51 RAM
Plugin Configuration window, 48 available for mysqld, 91
Plugins tab, 48 Registered Ports, 70
Pop-up relative path
editable pop-up list, 133 exclusively, 153
Pop-up button, 129 remote user
pop-up list giving access to, 33
preserving, 129 remove Action, 154
pop-up menu request restore, 49
two-tiered, 34 request shipment, 49
Pop-up Values list, 112, 114, 117, 119 Restart Daemon button, 213
port number, 70 RESTORE_FULL, 99
ports RESTORE_QUICK, 99
getting a list of, 70
reverse-proxy server, 73
shutting down unnecessary, 72
robot, 73
preview, 19, 39, 189
controlling size, 39 roll-over text, 44
deleted or corrupted, 207 root, 3, 5, 33
for EPS and PDF files, 32 Rule Set Summary, 161
generating for all existing images, 32 Run Action column, 141
InDesign and QuarkXPress, 18
inside the WebNative Venture database, 60
large, stored in WebNative Venture, 207 S
large web generated on-the-fly, 18
logs of web-ready generation, 60 save times
not read into database, 243 avoiding slower, 18
of layout files, 46 Schedule Database Verification, 97
recovering small, 207
Scitex, 1
stored big, 95
storing, 244 searching
style, 45 fulltext, 109, 124
indexed, 109, 124
print Action, 154
search on partial words, 109
ProgramName>Drop Index button, 92
searchquery.js, 125
proxy server, 72, 73, 74
secure protocols, 72
Secure Sockets Layer (SSL), 75

262
 Index

security, 69, 73 stored big preview, 95

increasing, 71 store FPOs, 89
server style
connecting to top level, 33 set on volume, 48
DNS, 74 styles, 43, 44
external web, 74 basket, 46
proxy and reverse-proxy, 73 browse, 46
virtual, 74 default, 44
SERVER.err, 219 house, 44
setdatafield Action, 154 imageinfo, 46
Setup Complete dialog, 13 language, 47
SGI Image Library, 1 list, 44
mview, 46, 47
shell window, 6
order, 47
shipment, 49 quarkview, 47
shopping basket, 42 search, 47
administer, 49 simple, 44
clearing, 51 toplevel, 47
clearing a collection from, 50 upload, 47
default features, 51 Styles tab, 44
loading, 51
SubAdmin
loading a collection, 50
see subadministration, 53
saving the relation of a collection, 50
subadministration, 53
shortandlist style, 45
subdirectories, 38
Short View, 39, 40
limiting access to, 38
Show All Files, 42 user has access to, 38
show archives, 42 superuser, 3
Show Comments, 40 Support Webnative on this volume, 31
Show History, 40 Suspend Processing, 97
Show Linked Files, 41 sync, 243, 244, 245
Show Versions, 40 default periodic, 247
Slow Queries, 91 is it running?, 215
smallbuttons style, 45 only a small part of the database, 216
SMALLINT, 113 out of, 216
scheduled, 247
Small Preview, 39
while browsing, 247
read into database, 207
without a -delnorm, 248
small web preview, 88, 94
syncvolotdb.exe, 215
SMB/NFS volumes
syncvoltodb, 95, 215
keeping in sync, 216
reading FlashNet indices, 207
snort, 78 writing XMP, 179
Software Manager, 7 syncvoltodb(1M), 209, 216, 248
software requirements, 2 -archonlynopicts flag, 210
Solaris, 2, 5, 6 -delnorm, 210
SPARC, 2 -dir flag, 209
spider, 73 syncxmp, 179, 220
SSL-aware Apache log for, 218
setting up, 77

263
Index

T removing, 144
testing, 144
tab field separator, 201 Trigger Set Active Paths view, 161
telnetd, 70 Trigger Set Details view, 162
Temp directory, 91 Trigger Sets subtab, 161
templates, 127 Trigger Set Summary page, 143
adding, 128 Trigger Set Trigger Rules
assigning to users, 131, 135 troubleshooting, 162
classic, 128
triggers.log
copying, 128
file size limit, 165
creating a subset, 131
customizing for individuals, 131 tripwire, 78
deleting, 130 two-tiered pop-up system, 34
deleting fields from, 129 typographical conventions, 2
editing, 130
getting information about, 127
IPTC, 128 U
NAA/IPTC, 128
preserving pop-up lists, 129 update WEB FPOs, 32
Templates pop-up list, 128, 130 upgrades to a pre-existing WebNative installation, 5,
Templates tab, 127 219
text field, 108 upgrading FullPress, 10
Thread Concurrency, 91 upload, 45
threads, 90, 217 Uploader
thumbnail, 18, 19 Configuration for, 136
KeywordCache file, 136
thumbnail capture feature, 207
Uploader.log, 136
thumbnail previews, 207
Uploader Manager, 23
TIFF, 1
log files, 135
Timestamp data field, 163 preferences, 135
TINYINT, 113 upload function, 1
Today button, 117 uptime, 217
token search, 124 uptime for the session, 90
transaction log, 92 URL, 69
Transport Layer Security (TLS), 75 matching against a list, 71
Trigger Log, 56 Use Current Values, 133
trigger.log, 172, 174 Use Current Values button, 112, 114, 117, 119
Trigger Rule, 137, 147 Use Custom Pop-up Values, 133
multiple matching a condition, 164 Use Custom Pop-up Values button, 111, 114, 116, 118
removing, 144
user accounts, 35
Triggers and Rule Sets, 64
user.js
Trigger Set, 165
user.js file, 48, 182
adding Active Paths to, 164
adding new data field, 163 user lists, 27
editing, 162 Username
files, 169 logging in under a different, 45
naming, 162 userperms, 243, 244, 245, 246
preparing for, 147 User Perms tab, 131

264
 Index

User tab, 35 Volumes link, 88

user volume name, 38 volumes setting summary, 87
Volumes tab, 38, 87
volumestyles, 48
V

Value Trigger, 147, 168 W

/var/adm/appletalk, 213
/var/adm/appletalk/triggers.log, 165 watermarks, 32
/var/adm/webnative/dblogd.conf, 105 WebCrawler, 73
/var/adm/webnative/volumestyles, 48 webdblog, 213
Venture log, 56, 101 appearing without WebNative Venture being used,
venture.log, 218 102
venture.log, 216 WebNative
administration, 33
venturelog.old, 218
configuration, 33
verification, 96 preferences, 105
schedule, 97 volumes enabled for, 38
version WebNative administrative GUI, 33
managment, 24
WebNative Helper for Firefox, 17
versioning
WebNative ID, 16, 19
strategy, 156
configuring, 18
versioning plug-in, 24 preferences (InDesign CS and CS2), 18
Versioning plug-in for Photoshop, Illustrator, and WebNative logo, 33
InDesign, 40
WebNative.pkg, 8, 28
version management, 24, 40
webnative/userperms, 33
versions.conf, 40
WebNative Venture, 85
Versions folder enabling, 86
changing the default name, 40 internal structure, 86
Video Support plug-on for WebNative Venture, 89 WebNative Venture with Video Support, 89
View Log button, 57 WebNativ.exe, 9
Virtual Private Network (VPN), 74 WebNative XT, 16, 41
volume configuring, 18
completely disable, 246 drag and drop feature, 19
denying access to, 52 preferences (QuarkXPress), 18
enabling for first time, 243, 244 WEB Options, 32
organization, 38
web preview, 88, 89, 94
resubmitting without change, 245
syncing, 88 web protocol, 70
user, 38 web server, 27
user access to, 38 web view access restrictions, 32
user volume name, 38 Web volumes
Web, 38 establishing, 38
Volume History Size, 106 welcome.html, 7, 8
Volume Management button, 31 Well Known Ports, 70
Volumes for pop-up menu, 52 Windows, 2
Volumes for pop-up menu, 38

265
Index

X date metadata, 119

embedded vs. associated data, 181
xfnaction, 150 entering data, 179
Xinet Technical support, 6 exporting, 202
Xinet Uploader, 23 field naming standards, 111
template settings, 133 fields becoming editable, 122
floating point metadata, 116
XML, 201
integer metadata, 113
XMP, 85, 179, 201, 243, 244 naming standards, 110, 112, 115, 117, 120
adding custom fields, 181 prepended namespace, 182
adding metadata, 121 problem with, 218
associated vs. embedded data, 179 text metadata, 111
client-side form, 182 UserPerms consideration, 132
daemon that write to database, 220
XT.sit, 16
data format, 179

266