This documentation is for Brladmin 4.0 All versions of Brladmin give the revision number when run without arguments. Thus the revision number can easily be checked.
Brladmin 4.0 is designed for optimal ease of use with ERL 4.0x, servers. It can be used with earlier servers, ERL 2.1, 2.0 and 1.2 but some special procedures may need to be followed. (See 4.4. Use With Older Servers ).
The copyright on this document and all its parts belong to SilverPlatter Information Ltd, 10 Barley Mow Passage Chiswick, London.
Brladmin, often referred to just as brl, is a script-orientated client for performing administration on one or more ERL servers. It provides command line access to all commands that an ERL server is capable of processing.
Brladmin is designed to provide the maximum flexibility in administering an ERL server. Such flexibility means that the broad spectrum of uses of Brladmin is inevitably ill-defined.
The original purpose of Brladmin was two-fold:
To provide a means for ERL administrators to process large files of database and user administration information on a batch basis.
To provide a means for ERL administration to be done with other packages (such as propriety dbase products), with particular reference to the requirements of a Partner Hosted Server. Since then other purposes and possible purposes have emerged, however the above should still be taken as the raison d'etre for Brladmin.
The main files in Brladmin once installed are as follows:
List of Files In Brladmin Installation | |
---|---|
brl
| Brladmin executable. |
plist.lst
| File used by brladmin to assist with command parsing. |
keydata.dat
| File of random data used for checksum encryption |
spcore.err
| Error message-number file. |
toolerr.err
| Error message-number file. |
readme
| Stop-press information about the package. |
brladmin.cfg
| Brladmin configuration file. |
erlclnt.cfg
| General client configuration file, including the address(es) of potential servers. |
erlping
| Utility for checking presence of an active server. |
All of these files are unpacked into
/sproot/bin
In addition, documentation may be found in
/sproot/brladmin/doc.
All supporting files will be searched for locally first, and if not present, then in the same directory as the executable, (where they are initially unpacked to.) Thus it should be possible to run brladmin on scripts contained in any local directory with directory-dependent local configuration files over-riding the supplied ones as required.
Thus, although there are many ways to use brl, my recommendation is to
include
/sproot/bin
in the
PATH
and have scripts in as many other directories as required. "Override"
erlclnt.cfg
files can also be held here.
Erlping is a utility, completely seperate from brladmin, but supplied with
it. It is slightly analogous to the well known network utility ping, except
that it makes contact with an erl server rather than just a machine. It
returns some information about the server if it is successful and an exit
status. It has NO supporting files, and does not use
erlclnt.cfg
It is used like the ping utility, for example, as follows:
"erlping 192.80.71.42"
The address above is currently one of SilverPlatters Internet Subscription servers. If your machine has connectivity to this one over the internet, then you should see the following typical output:
*********************************************************** Server id: SP$boston5 Server Name: Boston5 Server type: 1 Server Description: Silver Platter DXS Database Server Prefix: SP$ Version: 7 DXP version: 20 Login Required :YES Organisation ID: silverplatter Organisation name: SilverPlatter Information Site ID: IntSubs Site name: Internet Subscription Services
A simple help message is produced if run without arguments.
Brladmin can form the link between an ERL server and a seperate Customer Database (CDB). There are many ways that Brladmin and a CDB could be linked together. The present intention is that the CDB generate a series of short files and these will be processed by Brladmin in strict chronological order. An additional option is that Brladmin can generate a file to be read by a CDB to indicate it's progress and act as a receipt.
Brladmin and the CDB may be run on the same machine or on different machines with shared filing systems. Brladmin and the CDB may even be run on machines without shared filing systems, where some other means of transferring files is used although this is not recommended.
Brladmin is provided as a tool for a PHS to use. At this time Silverplatter does not provide an `out-of-the-box' customer database to a PHS since requirements may vary significantly from one PHS to another.
At the outset it must be said that not much is known about this mode of usage.
That said, there are features that are specifically aimed at other users. For example the ability to provide a script with a checksum and the validated output facility.
Brladmin can be used with older servers such as those from ERL 2, 2.1 and even 1.2.
As a practical matter it is necessary to copy copy one of the 3 files
plist1.lst, plist2.lst
or
plist4.lst
over the top of the active file
plist.lst.
The files
plist1.lst, plist2.lst
and
plist4.lst
play no other part in the installation and are never referenced by brladmin directly.
As supplied, the file
plist.lst
is the same as the supplied file
plist4.lst
which is for use with Erl4. For use with Erl2,
plist2.lst
should be copied,
and for use with Erl 1.2
plist1.lst
should be copied.
If you update or change the server you are talking to, you should update the
plist.lst
file.
The command line for Brladmin is generally:
"brl option(s) filename(s)"
Specifically, the following options are available:
Command Line Options | |
---|---|
-c | Provide a commentary detailing syntactic information about commands as they are parsed. |
-p | Progress quote mode on. (See 6.1. Syntax ). |
-n | Syntactically check the file(s) only. Send no commands to any ERL server. |
-s | Produce checksum-stamped copy of the input file(s) on the standard output. In order for this to work the file should contain at least 1 login command and 1 password. No commands are sent to any ERL server. (See 12.2.3. Checksum ). |
-e | Update the sequence file every command instead of for every file processed. (See 17.1. Sequence Numbers - Use with A CDB. ). |
-r | Used to set the number of network retries in total. May need to be increased over slow or error-prone links. Each try times out after 30 seconds. Once this number of retries is exhausted, the program exits. |
-i0 -i1 | i0 gives non-interactive mode- no error messages or other output. In this
event error messages are
stored in the file
brllog.log.
i1 gives the possibility of more user interaction.
ALWAYS SUPPLY -i0 UNLESS USING INTERACTIVELY.
|
-I file | Similar to
-i0
but use the file named
file
instead of
brllog.log
|
-j n | This option is intended for SilverPlatter's internal use only. Fool Brladmin into thinking that the server internal version as reported by erlping is n. For Erl 2.1 n would be 9. |
-m name password | Supply username and password on the command line. Both must be supplied if the -m option is used. |
-a | Following the 'a' an address should be supplied in symbolic or numeric
form and following this, using a / as separator, may optionally be supplied a
tcpip port number if this is not the standard ERL server port 416. This
address is used before any in the
erlclnt.cfg
file and in addition to any
in this file.
|
-v | Following the 'v' a server id should be supplied. This will be effective only on login commands that do not have server parameters. (See 12.2.4. Server ). |
-d | Each brladmin script file processed will be deleted after successful execution. |
name | Process the file name as a Brladmin input script. - is recognized as `read the standard input until end-of-file.' |
@name | Read the file name and treat each line as a further file name to process. - is recognized as 'read the standard input until end-of-file.' |
@- | Read the standard input until end-of-file, treating each line read as a file name to be processed as above. |
Command syntax is as follows:
[N] COMMAND PARAMETER=VALUE PARAMETER=VALUE ... etc
Braces {} are to be be used for multi-line parameters, so that if the 1st line contains a { then all new lines are treated as white space until a closing }. Thus the following might be one way to enter multi line commands. Tab will be treated the same as space, and any combination of newline characters will be allowed.
[N] COMMAND { PARAMETER=VALUE PARAMETER=VALUE PARAMETER = VALUE }
[N]
is meant to signify an optional sequence number. This number can
be used by Brladmin to refer to the command in status reports.
Lists of things are separated by commas, although only certain parameters of certain commands allow lists. Thus the way is clear for other parameters to pass comma-separated data directly to the server. Where multiple lists are used the command is sent once for each of the possible list combinations. Exactly what command-parameter combinations is indicated in the table of parameters by command, 20. Table of Parameters By Command
Optionally, string parameters may be placed in double quotes. This is necessary to place spaces within strings. Double quotes can be placed in strings by escaping them with the back-slash character, \. Backslashes themselves can be escaped by using a double-backslash. There will be no support for placing control characters in strings.
A special mode using a different convention has been implemented for use by applications written in the database language Progress. The definitive idea here is that this will conform to Progress quotation conventions for quotes within strings. Briefly, this convention is that a quoted quote is indicated by the doubling of the quotation mark.
Progress mode is obtained by using the
-p
option or the
progressmode
command within a script.
In both progress and non-progress mode \n and \r will be recognized as signifying carriage return and line feed. This is needed in the format and possibly dformat commands.
Normal comment convention is text delimited by # newline. For example:
# This adds user smith ADDUSER NAME=smith DESC="Puts horse shoes on horses." # This next line is commented out: the description is not accurate: # ADDUSER NAME=smith DESC="Grinds corn, makes flour"
The Brladmin command language consists of about 36 commands and some 55 parameters. Symbolic parameter values and other miscellany brings the total number of key words recognized up to about 160. Although by no means all parameters are valid with all commands, there are many instances where this is the case. It was an initial aim of the language to reduce the number of keywords to a minimum so that it could be as simple as possible. For example to add a user and to add a portfolio the "name" parameter can be supplied for either command. The aim was consistency across commands. Unfortunately other commands require both a user and a portfolio each identified by name, so that new names for the parameters (portname, username) have been used here. The overall result is that there is a certain amount of inconsistency in the parameter names used with various commands. To help alleviate this, synonyms have been allowed in some places, but not all places where this would be desirable.
The definitive source is the table at the back of this document which gives the parameters that are legal for each command. This table is taken directly from the source code: in the case of conflict with the text, the table is the authoritative source. If you find that a command does not work because of incorrect parameters, my advice is to consult this table.
At this stage a couple of complete examples might be useful. These use features not so far covered in the manual but give a good idea of the general outline of a brladmin script
This example will create a user called `noddy' on any server that it is run against.
login name=admin password=admin adduser { name = noddy exist = any password = tinklebell expiry = 1May98 Maxlogins = 5 ref= noddy@toytown.com desc= "Strange fellow with a weird blue hat." }
login name=admin password=admin login name=admin password=fkutr-u exportusers { name=noddy,bigears format="%name% %expiry% %desc%\n" }
This example when executed, attempts to login to the server on the command
line (if any) and then each of the servers in the
erlclnt.cfg
file with the username admin and the password admin. If all this fails the
same is tried with the second username and password.
If the first login succeeds, the second will be ignored. If both fail, a
login unsuccessful error will be generated.
The script will export the name, expiry and description for the users noddy and bigears, subject to existence of each.
The basic commands are:
The ADDUSER command adds users, as you might expect. The DEFAULTUSER command performs no action, but stores away any parameters supplied and uses them each time subsequent ADDUSER commands are sent, as explained below. These commands have a similar parameter list. In each case all parameters are optional, and in fact most parameters will not normally be supplied. If a parameter is omitted from the ADDUSER command, then this parameter defaults to the value used in the most recent DEFAULTUSER command. If the parameter was absent in the DEFAULTUSER commands or the DEFAULTUSER command is not used then the result is undefined.
When a user is added there are three possible conditions that may apply: The user must exist already, the user must not exist already, or the user may exist already. This is controlled by the EXIST parameter.
For ADDUSER some parameter that identifies the user MUST be given. This might be the username or the internal id. If the user does not exist already then the internal id cannot be given (since it is allocated by the server).
(Often incorrectly referred to as user id.) The name for the user. This is up to 31 characters long.
Internal ID- this may be used as an alternative to username for existing names. It is an error to use the Iid parameter with the Adduser command if the Iid value given is not the Id of a currently existing user.
This will be double-encrypted and will be transmitted without further encryption to the server. If the password begins with a ~ then a numeric value in decimal is expected and will not be encrypted before being sent to the server.
On export, the password field will always be in the double-encrypted form. The server has no knowledge of the un-encrypted passwords so that these cannot be exported.
The PASSWORD field is special in one respect. If the EXIST parameter is set to ANY then even if supplied the password is not updated. To change a password, the EXIST parameter must be NO (for new users) or YES (for existing users). This provides a way of restoring user data without changing password data, which after all may be under the users control.
An optional description field that is only stored but not used by the server. It has a maximum length of 57 characters.
An optional reference field that is only stored but not used by the server. It has a maximum length of 31 characters.
Takes the value Y or N. When Y login is disabled for the user.
This gives the rights of the user. Much the same as ERLADMIN, there are effectively 5 states: Accounts administrator, db administrator, guest administrator, or none of the above. (Normal, non-administrative users.) An additional state, which is both user and database administrator is included. The values are as follows:
Value | Permission | Hex Value |
| (See Below)
| |
NORM
| Non-Administrative User | 00000000
|
ACCAD
| Account Administrator | 00C00000
|
DBAD
| Database Administrator | 00300000
|
ACCDBAD
| Account and Database Administrator | 00F00000
|
GUESTAD
| Guest Administrator | 00500000
|
Note that
ACCAD
and
DBADD
give read/write access as user or database administrator while
ACCDBAD
gives read/write access to both.
GUESTAD
gives read only access to both. Except in the case of
ACCDBAD
this behavior is identical to erladmin. (
ACCDBAD
is not offered in erladmin.)
A hexadecimal number may also be given as a permission. This allows fully customizable permissions to be given. The hexadecimal number for the symbolic permissions are as given in the third column. The most common use of hexadecimal numbers here is for writing information dumped by a brladmin script, since these are always dumped as hex numbers. The table below shows the meaning of all of the relevant hex digits- composite values can be got by adding (or OR'ing) together the simple values given below.
Value | Description |
80000000
| Silver Platter Privileges |
40000000
| Installation Privileges |
00800000
| Account Administrator Write Privileges |
00400000
| Account Administrator Read Privileges |
00200000
| Database Administrator Write Privileges |
00100000
| Database Administrator Read Privileges |
00000100
| Can Modify Own Password |
These are taken from the ERL technical specification,
Note that it is a feature of ERL that permissions numerically greater than that of the current user cannot be set.
Expiry date of this user. The format is the same as for other dates in Brladmin and is defined by the following examples.
Expiry=15OCT95
Expiry="15 Oct 95"
Expiry="15 October 95"
Expiry="15 October 1995"
Expiry= %5975
Expiry="215 DAY 1995"
In general all spaces are optional and month names may be in 3-letter
abbreviated form or in full and are case independent. If in the place of the
month name the word DAY is given then this is taken as being an absolute
day-reference within the year. If in doubt you should use the
date/month/year format.
The % character followed by a decimal number is also valid. This is intended for debugging but may have its uses outside of this. The decimal number is not interpreted and is sent directly to the ERL server. This is interpreted as a number and is sent without further interpretation to the server. Users of this feature should note this is a highly server dependent feature, and what the number represents (for example seconds or days) may change between ERL versions. For ERL 2.0 it is in days since 1/1/80. In order to allow scripts that export say yesterdays or last months statistics, the following identifiers are also allowed: For Day or Date:
TODAY | Uses todays numeric date of the month in the date field. |
YEST | Uses yesterdays numeric date of the month in the date field. |
DBY | Uses the day before yesterdays numeric date of the month in the date field. |
ENDDAY | Uses the last day of the specified month. |
For Month
THISMON | Uses the current month in the month field. |
LASTMON | Uses the previous month in the month field. |
For Year
THISYEAR | Uses the current year in the year field. |
LASTYEAR | Uses the previous year in the year field. |
These rely on the local clock. Thus they are likely to be at best unreliable across time zones. The local clock may also be unreliable. However all the above will work even on the first day of the month or the first month of the year (or both!).
The following are valid examples:
ENDDATE="TODAY LASTMON 1998"
ENDDATE="DBY JULY 2005"
The following applies when using Brladmin 2.1 or after and an ERL 2.1 or ERL 4.0
server. In ERL 2.1 It applies only to users. - not statistics export or other things
that expire like portfolios. In ERL 4.0 users, portfolios and stats all
can have times associated with expiry.
An optional time may be given after the date. For example:
Expiry="5NOV98 20:32"
Would expire the user at 8:32pm on that day. This is a new feature on the
erl 2.1 server and is silently ignored if earlier servers are used.
(Expiry then taking place at 11:59pm on the day in question.)
Maximum number of days between password changes.
Maximum number of logins.
This takes the values Yes, No or Any for must exist, must not exist and may or may not exist before the add command. A default value of "no" is built in. If the condition is violated, an error occurs.
Ipincl is an IP address and a subnet-mask (space-separated) that login will be allowed from.
Ipexcl is an IP address and a subnet-mask (space-separated) that login will be disallowed from.
Either parameter may take the form
@filename
in which case the directory (on the server)
/sproot/cfiles/IDENT
where IDENT is the USERID in hex
for that particular user. This should be exactly 8 characters long,
including all leading zeros, and should use lower-case alphabetic
characters.
If the file exists then the contents of this file is used.
If the file does not exist then the directory
/sproot/cfiles
is checked to see if it contains the file, and this file is used.
For the format of the files on the server, the server documentation should be consulted.
If the parameters are unspecified the server defaults are applied. These are currently blank, thus login would be allowed from no IP address.
The DELUSER user command uses exactly one of username or user internal id number to specify a user to be deleted. No other parameters are used. Deletion is final: there is no way back.
Note that deleting a user implies that authorizations to portfolios for that user are deleted. (See Commands Concerned with User Authorization, 10. Commands Concerned with Authorization )
The
DISABLE
command is similar to the delete command except that deletion
is not necessarily permanent. DISABLEed usernames cannot be used although
the statistics are kept by the server and can be downloaded.
A DISABLEed user may either be deleted or ENABLEed, with the
ENABLE
command. The
ENABLE
command restores a user to the same status as before
the DISABLE command was used. DISABLEed users may have statistics
exported or may have their characteristics modified or exported.
No other operations are possible on DISABLEed users.
It is not an error to ENABLE a non-DISABLEed user or vice-versa.
These two commands delete all disabled or enabled users respectively. They do not use any of the parameters.
Server support is required for this command and is not available at the time of writing.
The user name to be deleted DISABLEed, or ENABLEed. It can be set to '*' to enable or disable all users.
As an alternative to Name, the user id number as allocated by the server may be given.
To import users the list of users and characteristics in whatever format available should be converted to the brladmin script language. The export of information in the old erladmin comma-separated list format can be achieved directly in brladmin script language by choosing an appropriate format string.
As is the case with all export commands there is a duel level hierarchy of default commands. If a parameter is not supplied to the EXPORTUSERS command it is looked for in the most recent DEFAULTEUSER command. If it is not present in the most recent DEFAULTEUSER command then it is searched for in the most recent DEFAULTEXPORT command. If it is not found here then the parameter is absent, and not sent as part of the command. The DEFAULTEXPORT command applies to all the export commands while the DEFAULTEUSER applies only to the EXPORTUSERS command.
The export users command writes data about users in a format specified by the
format
parameter.
The format for export includes, but is
not limited to the normal comma-delimited format of erladmin.
It is a comma-delimited list of usernames that will be exported, each of which can optionally contain a trailing wildcard '*'. For example
"EXPORTUSERS NAME=mw*,sp*,admin"
This would export all users with names starting mw then, all users with names starting sp, and also the admin user.
If specified, (as a non-empty string) then this parameter causes information about users logged in to the database to be returned. For example,
DB=MLA4
would return users logged in to this particular Medline volume. This identifier is always at least 4 characters, but may in certain cases be longer.
If specified as "*" then information about users currently logged into the server are returned.
If the parameter is not specified or is empty these are the same.
In general you should specify either Name, Iid or Db for this command. You also need to take care that the value of the db parameter is not inherited from the DEFAULTEXP or DEFAULTEUSER commands. The safe thing to do here is always specify Db="".
This parameter gives the filename for read or write. It should be a valid file or path name on the native operating system. Brladmin itself will support a filename or pathname up to 128 characters long. On Microsoft Operating systems such as Windows 95 and NT any '/' will be translated to '\'. This means that scripts may always be written with forward-oblique directory seperators as used in the UNIX operating system even when the scrip will not be run under UNIX.
This parameter controls the behavior when Brladmin opens files. It may take one of the following values:
NEW | An existing file of this name will cause an error. |
CREATE | An existing file of this name will be overwritten. |
APPEND | An existing file of this name will be appended to. |
This parameter acts like a picture of the generated data. Thus the following command
exportusers\ format="username=%name%\en"\ name=markw,kevinco
could produce the following output:
username=markw username=kevinco
%username%
in the format string has been replaced with the actual username. Note also
that \en are used to introduce carriage return-line feed at the end
of a line. The full list of allowable identifiers is as follows. Each must
be surrounded with %% in order to be replaced by the value of the relevant
quantity. Note that what is allowable in a format string depends upon
exactly which export command is being used. The list below is for
EXPORTUSERS
name
|
iid
|
updateseq
|
created
|
updated
|
password
|
desc
|
ref
|
disabled
|
nodelete
|
permission
|
expiry
|
pswlife
|
pswchanged
|
logindate
|
logintime
|
totlogins
|
totttime
|
totdchrge
|
totcchrge
|
maxchrge
|
maxlogins
|
logins
|
ipincl
|
ipexcl
|
Note that
password
can only be exported in double encrypted form, a decimal number.
and that
disabled
and
nodelete
will be exported as having values 1 or 0, not their symbolic values.
Fields that generate dates in the formatted output (these are
logindate,expiry,updated,created, in the above list.) use the
dformat
parameter to format dates. This consists of ASCII characters which will be
printed out unmodified and %x character pairs, where % is the percent sign
and x is taken from the table below. As with a
format
string, the
dformat
string forms a picture of the final output and the %x character pairs are
replaced by some part of the date. Unlike the
format
string above
there is no closing %.
%a
| Abbreviated weekday name. |
%A
| Full weekday name. |
%b
| Abbreviated month name. |
%B
| Full Month Name |
%d
| Day of the month as a decimal number (range 1 to 31) |
%j
| Day of the year as a decimal number (range 1-366) |
%m
| Month as a decimal number (range 1-12) |
%U
| Week of the year as a decimal number, Sunday as 1st weekday. (range 0-51) |
%w
| Weekday as a decimal number (range 0-6, Sunday=0) |
%W
| Week of the year as a decimal number, Monday as 1st weekday. (range 0-51) |
%y
| Year without century. |
%Y
| Year with century. |
%%
| A single percent sign. |
The following can also be used where there is an associated time, (erl2 only).
%H
| Hour in 24 hour format. |
%I
| Hour in 12 hour format. |
%p
| Am/Pm indicator. |
%M
| Minutes. |
%S
| Seconds |
Thus to generate a date of the type 25Oct1995, the dformat string would be used:
dformat="%d%b%Y"
and to generate a date of the type October 25, 1995AD. the dformat string
would be
dformat="%B\ %m,\ %YAD."
The quotes are necessary in the second example since it contains
spaces. For acceptability to Brladmin on input the format would be
as in the first example. Text not of the form %x is printed out verbatim as
in the 'AD' in the second example. There is a maximum length on any one date
of 70 characters.
Userid is a synonym for Iid.
(Commands concerned with portfolios can only be used with servers that support portfolios.)
A portfolio is a named collection of database-authorizations. Commands in Brladmin are needed to handle portfolios in much the same way that usernames are handled. In addition commands are required for defining the authorizations that make up a portfolio and for allocating users to portfolios. All licenses installed are also usable as portfolios: in this case the portfolio name defaults to the order number.
ADDPORT allows the definition and changing of portfolio information in the server. DEFAULTPORT allows definition of default parameters for the ADDPORT command. DELPORT deletes a portfolio from the server. It takes
The following is NOT implemented:
The portfolio cannot be deleted until all users authorized for the portfolio have either had their authorization revoked with an appropriate DELAUTH command or have had their portfolios changed to other ones. Deletion of portfolios that do not meet this criteria will result in an error.
NOT IMPLEMENTED
This command deletes all unused portfolios. There are no parameters.
Exactly one of these two parameters
is mandatory in all commands in this section except
DELOLDPORT
The Iid (Internal portfolio Id)
is a server allocated number for the portfolio. It can never be
changed.
It is an error to use the Iid parameter
with the
AddPort
command if the Iid value given is not the Id of a currently existing
portfolio.
This is a comma-separated list giving a collection of databases and dates covered. Each item in the lists consists of two or more letters that identify the database (the 'SetId') followed by a date specification. For example:
DATABASES="ML(199501-199602),PS(1995-1996),MX(1995-1996)"
Spaces are not significant provided the whole string is in quotes. If spaces are not present, the quotes can also omitted. Either 4 or 6 digits are used for each date depending on weather or not the month needs to be specified. 01 means January. For absolutely all access for all time specify the word ALL.
The DB parameter value is case sensitive: ML is not the same as Ml or ml. Conventionally all Silverplatter database setids have been upper case.
Description field for the portfolio. Of unknown utility.
Portfolios are enabled if this is set to 0.
This takes the values Yes, No or Any for must exist, must not exist and may or may not exist before the add command. A default value of "no" is built in. If the condition is violated, an error occurs.
Expiry date of this portfolio. The format is the same as for other dates in Brladmin. See 8.2.7. Permission
This sets the maximum number of concurrent logins allowed by any one username to through the portfolio.
One or other of these parameters should always be supplied. The parentname is the name of another portfolio and the parent is the iid of another portfolio. When creating portfolios, a parent must be supplied since creation of portfolios without parents (licenses) is only possible by the act of installing a license. The parent of a portfolio may be a license or any other portfolio. When access is attempted through the portfolio chain, the server will enforce the strictest limits of any portfolio in the chain.
These parameters set the corresponding portfolio fields.
These commands are concerned writing lists of portfolios, in exact analogy to the userexport command. (See 8.5. User Import/Export Commands )
This is similar to the format parameter in the EXPORTUSERS command. (See discussion in 8.5. User Import/Export Commands and under 8.6.5. Format ).
It is a comma-delimited list of portfolios that will be exported, each of which can optionally contain a trailing wildcard '*'. For example
"EXPORTPORT NAME=chemistry,bio*"
This would export all the chemistry portfolio and all starting bio, perhaps biology and biochemistry. Another example:
"EXPORTPORT NAME=0023*"
This might export all portfolios arising from order numbers 002300 to 002399 inclusive.
This is the same as for the exportusers command. (See 8.6.3. File ).
This is the similar to the userexport command. (See 8.6.5. Format ). The following list of identifiers are the only ones allowed inside the format string.
name
|
iid
|
updateseq
|
created
|
updated
|
desc
|
expiry
|
maxlogins
|
public
|
customer
|
sitename
|
prodcode
|
databases
|
logins
|
parent
|
parentname
|
disabled
|
See the EXPORTUSERS command Newfile parameter, 8.6.4. Newfile
The following commands deal with authorizations:
The PORTAUTH command has the effect of allowing a previously existing user access to a portfolio of databases. (Briefly, a portfolio is a subset of all the databases that a site has licenses for. In a server run by a third-party (a partner of SilverPlatter), a portfolio will in general correspond to an order by an individual or site for access to databases.) Such a server is usually referred to as a Partner Hosted Server or PHS. The license used or indeed the fact that a license exists for each database is resolved by the server when the license sheet is entered.
The DEFAULTAUTH command can be used to set up default values for the PORTAUTH command. It takes the same parameters.
Note that there can be multiple authorizations per username.
One or other of Userid or Username needs to be specified to uniquely identify the user to be authorized or un-authorized. ( ).
Name is a synonym for Username.
One or other of these needs to be specified to uniquely identify the portfolio to be authorized or un-authorized to.
This command allows the export of portfolio-style authorizations. This type of authorization is available only and exclusively on ERL2.X and 4.X servers and will will be referred to in the following paragraphs just as authorizations.
The EXPORTAUTHS command should on no account be used except with a 1.2 server. This command is not documented here. Use the EXPORTPAS command with 2.X and 4.X servers.
Authorizations (for ERL2) are specified uniquely by specifying a portfolio and a user, this is one authorization. A useful analogy might be that a point on a piece of paper is specified by an x and y co-ordinate; specify just one (x or y) and you specify a family of points a vertical or horizontal line. In the same way with authorizations, either the user or the portfolio may be specified or both. In the latter case it is not possible for more than one authorization to result.
Zero, one or two of the following parameters are used. As usual, both portfolio and user should only be specified in one way:
If both the user and portfolio are specified then a maximum of one authorization can result, although possibly the authorization specified will not exist. If one or other or both are not specified then all relevant authorizations will be returned. It is an error to specify either the user or portfolio by id and name.
The following identifiers only are legal within the format strings of the EXPORTPAS commands.
iid | Internal id of authorized user. |
userid | (synonym for iid) |
name | Username of authorized user. |
username | (synonym for name) |
portid | Portfolio internal id. |
portname | Portfolio Name. |
The output filename for exported data. Use - for standard output. (See 8.6.3. File ).
(See 8.6.4. Newfile ).
The modify database command is used to modify the characteristics of a mounted database.
These two parameters are synonyms, and are the database internal ID, for example MLA4.
The Db can take two other forms as well. The first is a comma-separated list, and the second is a series of values read from a file. The syntax for the latter is to start the parameter with a "<". The following examples should make it clear:
db=MLA4
Execute the command once for the specified database.
db=MLA4,ERA5,EBA2
Execute the entire command once for each of the three databases given, three times in all.
db=<myfile.txt
Read each line from the file
myfile.txt
and execute the command once for each line in the file, with the
parameter db set to the current file-line.
This field says what field should be used as the abstract field for usage based pricing purposes.
It should be a short field name, for example AB for the abstract field.
Additional charge per abstract. Note that all charges are delivered as integers. The normal interpretation will be that 1 unit is one penny, or the smallest unit of currency available. This is an interpretation issue though, not a functional issue and is outside the scope of this document.
Charge per 1000 characters.
Charge per record delivered.
Connect time charge.
The database description.
Set to 1 if the database is enabled.
Maximum charge which can be incurred. Zero means no limit.
Maximum connect time per session.
Set to 0 if authorisations are to be active. Set to 1 if everyone is to have access to this database.
(Previous versions of this spec said this was to be phased out in ERL2. This was incorrect.)
The EXPORTDBS command allows export of database characteristics. Parameters for the command are taken firstly from the command itself, if supplied, then from the most recent DEFAULTEDB command if available and then from the DEFAULTEXPORT command, once more if available.
The database internal id for export. Can be a comma-separated list.
This is a full or partial path name, valid for the operating system that Brladmin is currently running under. The special value file=- may be given to generate output on the standard output.
(See 8.6.4. Newfile ).
This parameter acts in a similar way to the Format parameter in other export commands. (See 8.6.5. Format ).
The following identifiers are legal within the format strings of the EXPORTDBS and DEFAULTEDB commands. Use of a wrong identifier will give an error message derived from the server (EC_BADKEY) and abort the script. Reference should be made to the parameters given in the MODDB command, 11.1.1. MODDB above. Usually this will make it clear what the situation is with regard to any particular identifier.
Name |
Iid |
Abstract |
Costdab |
Costdchar |
Costdrec |
Costmin |
Datescovered |
Detail |
Desc |
Dbsetid |
Dbset |
Dbfam |
Enabled |
Maxcharge |
Maxctime |
Maxlogins |
Mounted |
Noauth |
Period |
Dbset,Dbfam and Dbsetid are synonyms.
The Dformat string controls the format of any fields that are printed as dates. See 8.6.6. Dformat
This parameter should be given the value 0 or 1. When set to 0, only those databases that are currently mounted are delivered. When set to 1,
information about all database volumes that have ever been mounted is delivered. The default is
ALL=0
This command may occur one or more times but all login commands should occur
at the start of the script. If no login command is given then a simple
syntax check of the script is performed- no requests are made of the
server. This is then equivalent to the
-n
option.
If one or more login commands are present, each command is processed in turn until a successful login is obtained; subsequent login commands are ignored.
Within each login command the action depends on weather or not a username
parameter is supplied. If one is
NOT
supplied, then this is taken to be an interactive login request. In an
interactive login request first the
erlclnt.cfg
is read. If there is one server this is used. If more than one a menu
is presented and the user should choose the server from those presented.
Only those servers that can actually be contacted will be offered.
Once the server is chosen username and password will be prompted for for
that server.
To use the
-m
option, in which a username and password is supplied on the command line
It is still necessary to have a login command in the script, although
the username and password should not be supplied in this case.
In the case of a non-interactive login, which is presumed to be the
more usual situation, each login command initiates an attempt to login to
each server in the
erlclnt.cfg
file in turn until a login is successful.
One way of ensuring that only the desired server is logged in to, is to use the server parameter, this should match exactly the serverid. (This is a change from previous versions of Brladmin which wrongly matched the server name.) If the server parameter does not match in either interactive or non-interactive login then the login is considered to fail.
One server address, in addition to any in the
erlclnt.cfg
file may be provided on the command line and this is tried as the first in
the list. The -a option would be used, as in the following examples:
"brl -ahollie.silverplatter.com abc.bsx"
"brl -ahollie/5000 abc.bsx"
(The above shows a connection to a server not using the standard port number of 416.)
"brl -a193.130.112.123 abc.bsx"
It is also possible to specify the server parameter on the command line, using the -v option. However, the -v option will have no effect if a server parameter is given in the login command. For a complete list of command line options and explanations, see 5. Command Line Options
The username of the administrative user that Brladmin will operate as. If this parameter is not given then an interactive login will be sought for both username and password.
Normally the login performed by brladmin is the appropriate type of login that the server is using. This can be DXP login, Unix login, using a unix account password or DXP challenge. If the username begins with a tilde character (~) then this will be stripped off by Brladmin and a DXP login will be unconditionally used.
The corresponding password. This should be given in clear. The use of the password parameter to the login command cannot be recommended since it allows anyone who sees the script full administrative abilities.
This is an alternative to the password parameter, It consists of a hexadecimal sequence that may be up to 16 digits long. It is an encryption of the password parameter which is based on A position-dependent checksum of the script file. A secret data file. Thus not only is the password safeguarded by the secret file, but the script is proof against tampering.
If Brladmin is run with the -s command line parameter a copy of the given input script is generated on the standard output with the password parameter replaced by a checksum parameter in any login commands. The checksum parameter uses the document checksum and a file called keydata.dat (the secret file alluded to above), which should be at least 1.5k in size, to encrypt password and store this as the checksum parameter. All characters following the 1st login line are significant in the script except CR and LF. Thus an attempt to modify a script in any way will change the document checksum and this will result in an incorrect password at runtime. It is allowable however, to include comments before the login command- these, and only these comments are not included in the checksum and cane be modified without fear of making the file unusable.
The keydata.dat file should be kept secret at the point of generation and consumption of brladmin scripts. Availability of the file allows any one to generate valid brladmin scripts and execute them. The file can consist of ASCII or binary data but ideally should be non-deterministic in nature. (ie. pretend you are a monkey and type it in with a text editor rather than using last weeks financial report. )
The server parameter to the login command allows a login to be confined to
one particular server out of one or more that may be given in the
erlclnt.cfg
If this parameter is not given then the first successful login is used.
(Do not confuse the SERVER command with the Server parameter to the LOGIN command, 12.2.4. Server )
Normally a script is submitted to a maximum of one server. However for some purposes it may be useful to submit a script sequentially to different servers. The server command switches off all contact with a server unless the server id matches the name parameter. The commands are processed and all local effects occur, but no communication occurs with the server as a result of commands following a SERVER command when the server id does not match.
The special serverid ANY may be used to match to any server.
This the only parameter to the SERVER command above. It must be supplied where the SERVER command is used. It takes a value which may either be ANY in upper or lower or mixed case, or must match, character for character, the server name. This is a case-sensitive match.
There are certain administrative tasks that can only be performed by changing files on the server. These include things such as changing the structured data base list or the message of the day. Brladmin does not have specific commands for effecting these changes. It does provide a tool that can be used to fetch these files and write them back to the server system. This is like ftp with two differences. Firstly no additional password, apart from an ERL password is needed. Secondly only very limited access is provided in terms of what files can be accessed certainly nothing outside of the erl server for example.
One point to be aware of is that UNIX and NT store ascii files in different formats, so far as end of line is concerned. The file transfer commands here transfer files in a binary fashion, which means that the 'wrong' type of end-of-line may be seen when looking at files from one operating system on another. Careful use of the files will ensure that this is not a problem.
The available commands are:
Both commands have a similar set of parameters as follows.
The FROM parameter specifies where the file comes from and the to where it is to be copied to. For the GETFILE command, the FROM file will be on the remote machine while for the PUTFILE command the TO file will be. The remote filesnames always have the same syntax, which is independent of the operating system in use on the remote machine The syntax for a file name on the local machine, ie the machine that brladmin is running on. A file name on the remote machine consists of a location part and a filename part. There is no concept of a subdirectory. Two common locations are
Location | Directory on Server |
files | /sproot/files |
cfiles | /sproot/cfiles |
A full file copy then might look like this:
PUTFILE from="myfile.txt" to="cfiles:ip.incl"
or
GETFILE from="cfile:ip.incl" to="myfile.txt"
There is a special case with the cfiles location. Here the NAME or USERNAME parameter may be specified. (These are synonyms.) If it is specified then (on write) the file will be in the cfile/userid directory where userid is the numeric hex id of the user. On read if it is specified then the userid subdirectory will be looked in first.
The userid parameter may be specified directly instead of the username or name parameters. This is usually not a particularly useful thing to do.
A full example of the use of this command is as follows
LOGIN NAME=admin password=pyrethos GETFILE { from=cfile:ipincl to=/temp/ipincl newfile=create username=noddy }
/sproot/cfiles/0000001e
If it is not found hear then the server will look in the directory
/sproot/cfiles
Either way the file is then copied to the local file
c:\temp\ipincl
(assuming a Microsoft system and the current drive is C: ) and assuming that
the directory
c:\temp
already exists. If the file already exists it will be overwritten.
The following commands are available:
The EXPORTSTATS command can be invoked one or more times and each time it writes a body of statistics to an output file. Exactly what is written is determined by the parameters which are given below.
Like other export commands, the EXPORTSTATS command can take parameters from the a proceeding DEFAULTEXPORT command, from a DEFAULTESTATS command or from the EXPORTSTATS command itself. Parameters are taken from commands on a first-found basis in order of:
EXPORTSTATS DEFAULTESTATS DEFAULTEXPORT
This provides default values for the EXPORTSTATS command. It has identical parameters to this command.
This is a full or partial path name, valid for the operating system that Brladmin is currently running under. The special value file=- may be given to generate output on the standard output.
The following parameters are designated as keys. Usually between zero and 3 will be specified. Often they will be specified as '*'.
If a key is unspecified, it means that the records that result cover all possible values of the key. For example, if the username is unspecified than each record will be summed accross all users.
If a key is specified as '*' this is a request to give all information.
and have it split according to the key. For example if
username=*
is specified, each username will be listed.
If
username=* db=*
then every combination of username and database (for which there is activity)
will be listed.
An alternative way to look at this is that by NOT specifying
db=*
you make a request to summ accross all databases.
Note that in ERL 2.0 only DB and IID were supported and that the notation of using '*' was not except for IID. IID is a synonym for USERID, the numeric server allocated user number. The way to process all dbs was to generate a file containing all the dbids, and use a '<' to indicate that input should be taken from the file. This mechanismn is still supported for all the above keys.
In ERL 4.0 IID or USERID (which are synonyms) are an alternative to username but in fact it seems likely that username will always be prefferred.
The secret of getting the most from ERL statistics is the use of the appropriate combination of keys. The table below gives most of the main combinations with some comments on what the effect of using the combination is.
Effect Of Keys And Combinations | ||
---|---|---|
Ref | Keys Specified | Effect |
1 | (None) | Statistics for the whole server, not related to any individual or username, database, ipaddress or portfolio are returned. |
2 | USERNAME | Statistics for each specified user or all users are returned. There is no split by IP address, database etc. |
3 | DB | Statistics for each mounted database. No split by user, IP address or portfolio etc. In general using this key, giving a breakdown by database-instance, is more detailed than users want, although it is what we currently provide. The same comment applies to all case where this key is used. Much better are the DBFAM or PORTNAME keys. |
4 | DBFAM | Statistics by database family. No split by user, Ip address etc. Logins , connect time etc are for the family. |
5 | IPADD | For each specified Ipaddress or for all from which access occurs, statistics are returned, not split by username, database etc. In the case of gateways the gateway supplied end-user address will be used. |
5 | PORTFOLIO | Statistics for the protfolio are returned. This allows the usage made of a particular licence to be discovered, or the usage of a particular 'subscription' since in general a subportfolio corresponds to a SilverPlatter product. In the first case there is no split by database, all the databases are covered on the licence. Also there is no split by user, all usage by anyone is included. In the second case, the the same rules apply, but since the only use will have been made by the user or perhaps small group of users authorised the figures will be quite specific. |
6 | USERNAME, DATABASE | Split by username and database. Logins are to the database not the server. This is already in ERL2.1 |
7 | USERNAME, DB-FAM | More useful than 6 since a database family corresponds better to what the user percieves as a 'database' |
8 | USERNAME, IPADD | In systems where few usernames are used, this could be used to show usage patterns. |
10 | USERNAME, PORTNAME | Useful for licence portfolios or for subportfolios with several users authorised. Shows usage split-up accross the portfolios. |
11 | DB, DBFAM | Nearly useless, since each database is in exactly one family, the same as just by database. Not quite useless since it would be useful to say give me all the stats in this family, broken down by database (instance). |
12 | DB, IPADD | Not split by user or portfolios. Not particularly useful. Might be useful in special cases. DBFAM,IPADD would be more useful. |
13 | DB, PORTNAME | Not sure why you would use this. |
14 | DBFAM, IPADD | Useful where ip address is more important than username. Might tell for Example, which university departments were using which databases. |
15 | DBFAM, PORTNAME | Not sure. |
16 | IPADD, PORTNAME | Shows which products are used at which locations. No breakdown by user. |
17 | USERNAME, DBFAM, IPADDRESS | Full statistical breakdown to the database family level |
18 | USERNAME, PORTFOLIO, IPADDRESS | Similar to 17 , but referenced to PORTFOLIOS - ie SP products. |
19 | USERNAME, DATABASE, IPADDRESS | Similar to 17 , but referenced to a database-instance. Less useful perhaps. |
20 | PORTFOLIO, DB-FAM, IPADDRESS | Not useful so far as I can see. |
This is the date to start the usage statistics export. In ERL4 and beyond it can be specified to the minute or second.
The format for the date is the same as in other Brladmin date parameters. (See 8.2.7. Permission ).
This is the date to finish the usage statistics export.
The format for the date is the same as in other Brladmin date parameters. (See 8.2.7. Permission ).
This can take the following values. It is equivalent to "report style" in webadmin.
Total
| One record for the entire specified period, per key-combination. |
Detail
| One record per day per key-combination. |
Day
| ditto |
Daily
| ditto |
Month
| One record per calendar month per key-combination |
Session
| One record per session per key-combination |
Detail, Day
and
Daily
are synonyms for historical reasons.
Daily
is preffered.
Note that with Erl 2.X servers the only keywords that are valid are
Total
and
Detail
( or
Daily or Day
)
In ERL4. connect time a distribution data set is available for each statistic record.
That is for example for each database, portfolio, database-user combination in the statistics
output. There are a maximum of 100 points in this distribution, and the most straight-forward use is that each point represents the time in minutes spent at
a particular exact usage level, (Eg 5 users.) within the time period specified by
Startdate
and
Enddate.
The precise meaning of these points can be changed by specifying the filter.
The following are available:
EQL | No effect. |
GTE | Changes all points to the number of minutes at this number of connections or greater. |
LTE | Changes all points to the number of minutes at this number of connections or greater. |
This parameter controls the behavior when Brladmin opens files. It may take one of the following values:
NEW | An existing file of this name will cause an error. |
CREATE | An existing file of this name will be overwritten. |
APPEND | An existing file of this name will be appended to |
The EXPORTSTATS Format parameter is similar to the Format parameter in other export commands (See 8.6.5. Format ). Allowable %- delimited identifiers that may appear in it are as follows:
db
| Database internal id (dbid). Often 4 characters. |
iid
| User internal id. |
username
| User name. |
name
| Synonym for username. |
desc
| User description |
dbdesc
| Database description |
dbname
| Database name (NOT the (usually) 4 character dbid) |
portname
| Portfolio name. |
pdesc
| Portfolio description. (Sometimes known as product description.) |
ipadd
| IP address |
dbsetid
| Database family id, also know as set id. Typically two letters, eg ML. |
dbset
| (as above) |
dbfam
| (as above) |
ref
| User reference. |
servername
| Name of the server. Never changes. |
serverid
| Id of the server. Never changes. |
startdate
| Date and time of the first login (if any) within the record. Note that this name is somewhat MISLEADING. It is not the date/time the record started. This field may be blank if no logins occurred. |
enddate
| Date and time of the last login (if any) within the record. Note that this name is somewhat MISLEADING. It is not the date/time the record ended. This field may be blank if no logins occurred. |
lastlogout
| Date and time of the last logout (if any) within the record. Note that this name is somewhat MISLEADING. It is not the date/time the record ended. This field may be blank if no logouts occurred. |
firstlogout
| Date and time of the first logout (if any) within the record. Note that this name is somewhat MISLEADING. It is not the date/time the record ended. This field may be blank if no logouts occurred. |
firstmo
| Date and time of the fist moment that this record refers to. Is never blank. |
lastmo
| Date and time of the last moment that this record refers to. Is never blank. |
nwrecs
| Number of records delivered. |
nwabs
| Number of records delivered with abstract. |
nwchars
| Number of kilobytes of data delivered. |
totlogins
| Total number of logins. |
ctime
| Connect time in minutes. |
rejects
| Number of failed login attempts. |
totdchrge
| Data charges incurred (as an integer). |
totcchrge
| Connect time charges incurred (as an integer). |
peakusage
| The maximum number of connections to the database (and possibly user) within the time period. |
peaktime
| The time and date of ocuurance of the peakusage. |
searches
| The number of searches performed on the database (and possibly by user) within the time specified. |
ctd0..ctd99
| If the filter is not specified or is specified as EQL, these have the following meaning. Connect time distribution. ctd1 gives the connection time in minutes at exactly one user, ctd2 at exactly 2 etc. ctd0 gives the time at 0 users, but not including time that the server was down. |
SERVERID
| (A Constant string.) |
SERVERNAME
| (A Constant String.) |
LOGFLAGS
| Flags the type of logins that are being counted in TOTLOGINS. Can be U (User), F, (Database Family), D (database) or P (Portfolio). |
identifiers in the format string that generate dates in the formatted
output (these are
logindate,expiry,updated,created, in the above list.) use the
dformat
parameter to format dates.
(See
8.6.6. Dformat ).
This command is provided for debugging other things. The effect is to pause before continuing on to the next command. There is just one parameter.
This is the time in seconds to pause for.
The print command is provided as a convenience when debugging brladmin scripts or for placing a comment in a Brladmin output file.
The command is PRINT. It takes its parameters from the PRINT command itself, or failing that, from the most recent DEFAULTPRINT command, or failing that from the DEFAULTEXP command.
This is the text to be printed out.
This is the output file for the text to be printed to. As usual, - means the standard output.
This is the same as the Newfile parameter in other commands. (See 8.6.4. Newfile ).
It presumed to be essential that the current status of the server databases are reflected in a customer database (CDB) where used. For example, if a customer orders a subscription but is unable to access it, verification of the fact that the request has been submitted to the appropriate server and accepted should at some time be available to the CDB. This would enable someone consulting the database to either advise the customer to wait for a further day or two or that there is some problem that the administrator needs to investigate this. This means that as well as Brladmin accepting a script and executing it, some feedback in the opposite direction is required. The proposed scheme is simply to use the command sequence number (see 6.1. Syntax ) as a tag for the command and to have Brladmin signal when each command is executed.
To achieve this, Brladmin
writes the command sequence number to a file,
the
"sequence file"
with filename
sequen.seq
after each command or after each file of commands is successfully executed.
The sequence file may be examined by
the CDB at any time
to obtain feedback on where the execution sequence has got to. The route by
which the sequence file reaches the CDB is not important- normally it will
be by shared networked drives but in principle it can be e-mail, floppy disk
or even surface mail !
Normally Brladmin updates the sequence file only after each file is
successfully executed. If the
-e
option is given then the file is re-written for each command processed.
Thus information flows from the CDB to BRLADMIN in the form of
files (brladmin scripts), and confirmation of Brladmin transactions
is given to the CDB by means of the sequence file. Brladmin also reads
the sequence file on startup to ensure that the first transaction has
sequence
number one greater than that recorded in the sequence file.
CLICK HERE FOR DIAGRAM
Note that if Brladmin does not have access to the current sequence file (that was generated when Brladmin was last run) no further implementation of orders can take place. On the other hand if the link to the CDB is temporarily broken this will only cause the CDB to be out of date for the duration of the breakdown. For this reason I suggest that the sequence file should be on a locally mounted drive. A CDB should check the numbers in the sequence file and report an error if they ever repeat or decrease.
There are two ways of handling multiple servers. The aim of Brladmin is to facilitate both or either of these techniques. Method one is that separate scripts will be produced for each server, method two is that the same script will be fed to each server in turn.
Brladmin is not capable of connecting to more than one server at a time.
It is worth pointing out that this is a slightly "grey area" - not much is known yet about exactly how multiple servers will be administered with a single CDB. It is possible to imagine that servers will be split with all users on all servers, each server only having some of the databases, or that all servers will have all databases, users being split across the servers. The latter is currently the preferred model and this is assumed in the following two sections. The reason for this preference is twofold. First, it is more difficult to keep large numbers of users in step across servers than databases, and second, because change in the user-base is more common than change in the database-base.
If these assumptions do not hold in your environment then you should re-evaluate the conclusions of this section.
In general I recommend the use of this technique for multiple servers.
In this method the CDB generates a single script which is fed in turn to each server. Commands such as adding or authorizing a user are confined to a particular server by means of the SERVER command. As regards feedback to the CDB, separate sequence files are generated for each server: if the numbers inside them differ, the one with the lowest number is fed back to the CDB and an error reported. This could be achieved with a shell script under unix. A short shell script would run Brladmin for each server, compare the sequence files and forward the lowest one to the CDB, perhaps by copying it to a networked drive.
In general script files given on the command line should be sorted into lexicographical order of the initial command number contained in each file before submitting to Brladmin. This can be facilitated by using file names that contain this number as a prefix. Thus a lexicographic file sorting utility can ensure that files are submitted in the correct order. An alternative scheme is to use the creation time for the file. Where one or more files are given the order is highly significant Brladmin will not run if the files are not in the correct sequence.
Although many commands to a server can be made in any order, for example adding two users, in practice it should be assumed that the sequence of scripts must be run in exactly the right order on the server. For example, consider a situation where a users is created, deleted, created and deleted again. Clearly the exact order of these 4 operations is highly significant.
The
PROGRESSMODE
command is equivalent to using the -p command line option.
However, it is only effective from the point where it is used.
It takes no parameters.
(See
6.1. Syntax ).
The VALIDON command may be used to make Brladmin produce a 'validation checksum' before it exits. This is a security checksum that used to detect changes made to Brladmin output. This means that the output can be sent across an insecure network and later verified to ensure that it it has not been tampered with.
Output from Brladmin that was produced from a script containing this command can be checked by using the -k command line option. With this option most other options are ineffective, and no attempt is made to process the input file as a brladmin script: indeed the input will not normally be a brladmin script in this situation. The error status is set to 0 if the input file is considered un-altered and to 1 if it has been altered. The -i0 or -i1 options may be used to suppress/elicit a screen message in either situation.
The validation checksum includes all output produced by PRINT or EXPORT commands after the VALIDON command, whatever the output file. Thus it is generally possible to prepare validated output files at the same run of Brladmin that will never be re-validated. One simple way to make this error which illustrates the point is given by the script below.
validon file=myfile1 print text="The fox jumps" file=myfile1 print text="Over lazy dog" file=myfile2
The fox jumps
followed by the validation checksum,
and myfile2 would contain
Over lazy dog
It should be noted that the checksum covers the text
"in both files"
so that myfile1 will always fail a validation check.
The correct way to handle this is to use the VALIDOFF command- this
switches off the checksum until the next validon command. It does not stop a
checksum being produced, but it does stop it being altered by text or other
output that is generated.
validon file=myfile1 print text="The fox jumps" file=myfile1 validoff print text="Over lazy dog" file=myfile2
Use of the validated script feature described above and the CHECKSUM parameter to the Login command provides a complete security system to protect scripts and output produced by them from being changed by unauthorised persons.
The Exit command may be useful for debugging. It causes immediate termination of a brladmin script.
Normally commands and whole scripts are expected to run without error. This may sound obvious, but the point is that the assumption is made that errors are sufficiently rare that there will not need to be routine recovery methods.
The general situation is that when an error occurs, no further processing of
of any script occurs. The sequence files contain a sequence number
representing
the last successfully run command. The exit status of the
command will be set and an error message will be produced on the standard
error output and in the log file
brllog.log
, if used. This will typically result in
the inability to run Brladmin at all since the
sequence files will not be in sequence with the next command script.
The sequence file may be deleted or edited to remedy this once the problem
has been corrected.
These tables include some undocumented commands: these should in general be
ignored. Items marked * are expanded within Brladmin if a comma-separated
list is supplied. Where multiple * occur within one command, either the
parameters are alternatives (see the appropriate command and parameter) or,
where this is not the case, the command will be sent once for each possible
combination of the two (or more) lists. Items marked O are not sent if the
parameter is empty. Items marked with a "<" may use the syntax for reading a
list of things from a file. This is explained in more detail in
11.2.2. Db
+------------------------------------+ | Parameters by Command | +--------------+---------------------+ | Command | Parameter | +--------------+---------------------+ |addport | action | | | customer | | | databases | | | desc | | | disabled | | | exist | | | expiry | | | iid * | | | maxlogins | | | name * | | | parent | | | parentname | | | portid * | | | prodcode | | | sitename | +--------------+---------------------+ |adduser | desc | | | disabled | | | exist | | | expiry O | | | expirytd O | | | iid * | | | ipexcl | | | ipincl | | | maxcharge | | | maxlogins | | | name * | | | nodelete | | | password | | | permission | | | pswchanged | | | pswlife | | | ref | | | totcchrge | | | totdchrge | | | userid * | +--------------+---------------------+ |defaulteauth | db | | | dformat | | | file | | | format | | | newfile | +--------------+---------------------+ |defaultedb | db | | | dformat | | | file | | | format | | | iid | | | maxrecs | | | newfile | +--------------+---------------------+ |defaulteport | dformat | | | disabled | | | file | | | format | | | maxlogins | | | name | | | newfile | | | parent | | | parentname | | | portid | | | portname | | | prodcode | | | updateseq | +--------------+---------------------+ |defaultestat | db | | | dformat | | | enddate | | | file | | | format | | | iid | | | maxrecs | | | newfile | | | period | | | port | | | startdate | | | userid | | | username | +--------------+---------------------+ |defaulteuser | db | | | dformat | | | file | | | format | | | iid | | | maxrecs | | | name | | | newfile | | | userid | +--------------+---------------------+ |defaultexp | db | | | dformat | | | disabled | | | enddate | | | file | | | format | | | iid | | | maxlogins | | | maxrecs | | | name | | | newfile | | | parent | | | parentname | | | period | | | port | | | portid | | | portname | | | prodcode | | | startdate | | | type | | | updateseq | | | userid | +--------------+---------------------+ |defaultport | action | | | customer | | | databases | | | desc | | | disabled | | | exist | | | expiry | | | iid | | | maxlogins | | | name < | | | parent | | | parentname | | | portid | | | prodcode | | | sitename | +--------------+---------------------+ |defaultprint | file | | | newfile | | | text | +--------------+---------------------+ |defaultuser | desc | | | disabled | | | exist | | | expiry | | | iid | | | ipexcl | | | ipincl | | | maxcharge | | | maxlogins | | | name | | | password | | | permission | | | pswlife | | | ref | | | userid | +--------------+---------------------+ |delauth | db * | | | iid * | | | maxrecs | | | portid * | | | userid * | +--------------+---------------------+ |delauthbyname | db | | | maxrecs | | | name | +--------------+---------------------+ |deldisable | name | | | userid | +--------------+---------------------+ |delenable | name | | | userid | +--------------+---------------------+ |deloldport | iid | | | name | +--------------+---------------------+ |delport | iid | | | name | | | portid | +--------------+---------------------+ |deluser | iid * | | | name * | | | userid * | | | username * | +--------------+---------------------+ |disable | name | | | userid | +--------------+---------------------+ |enable | name | | | userid | +--------------+---------------------+ |exit | (no parameters) | +--------------+---------------------+ |exportauths | db *O | | | dformat | | | file | | | format | | | newfile O | +--------------+---------------------+ |exportdbs | dformat | | | file | | | format | | | iid *O | | | maxrecs | | | newfile O | +--------------+---------------------+ |exportpas | dformat | | | file | | | format | | | name * | | | newfile O | | | portid * | | | portname * | | | userid * | | | username *O | +--------------+---------------------+ |exportport | dformat | | | disabled | | | file | | | format | | | maxlogins | | | name * | | | newfile O | | | parent | | | parentname | | | portid * | | | portname * | | | prodcode | | | updateseq | +--------------+---------------------+ |exportstats | db *O< | | | dbsetid *O< | | | dformat | | | enddate | | | file | | | format | | | iid *O | | | maxrecs | | | newfile O | | | period | | | startdate | | | userid * | +--------------+---------------------+ |exportusers | class | | | db *O | | | dformat | | | file | | | format | | | iid *O | | | maxrecs | | | name * | | | newfile O | | | userid * | +--------------+---------------------+ |getfile | from | | | name | | | newfile | | | to | | | userid | | | username | +--------------+---------------------+ |login | checkip | | | checksum | | | name | | | password | | | server | +--------------+---------------------+ |moddb | abstract | | | costdab | | | costdchar | | | costdrec | | | costmin | | | costpab | | | costpchar | | | costprec | | | db *< | | | desc | | | detail | | | enabled | | | maxcharge | | | maxctime | | | maxlogins | | | name * | | | noauth | | | period | | | public | +--------------+---------------------+ |portauth | name *< | | | portid * | | | portname *< | | | userid * | | | username *< | +--------------+---------------------+ |portauthdel | name < | | | portid | | | portname < | | | userid | | | username < | +--------------+---------------------+ |print | file | | | newfile O | | | text | +--------------+---------------------+ |progressmode | (no parameters) | +--------------+---------------------+ |putfile | from | | | name | | | to | | | userid | | | username | +--------------+---------------------+ |server | name * | +--------------+---------------------+ |zeroauth | db | +--------------+---------------------+
These tables includes some undocumented commands: these should in general be
ignored.
+--------------------------------+ | Commands by Parameter. | +----------------+---------------+ | Parameter | Command | +----------------+---------------+ |(no parameters) | exit | | | progressmode | +----------------+---------------+ |abstract | moddb | +----------------+---------------+ |action | addport | | | defaultport | +----------------+---------------+ |checkip | login | +----------------+---------------+ |checksum | login | +----------------+---------------+ |class | exportusers | +----------------+---------------+ |costdab | moddb | +----------------+---------------+ |costdchar | moddb | +----------------+---------------+ |costdrec | moddb | +----------------+---------------+ |costmin | moddb | +----------------+---------------+ |costpab | moddb | +----------------+---------------+ |costpchar | moddb | +----------------+---------------+ |costprec | moddb | +----------------+---------------+ |customer | addport | | | defaultport | +----------------+---------------+ |databases | addport | | | defaultport | +----------------+---------------+ |db | defaulteauth | | | defaultedb | | | defaultestat | | | defaulteuser | | | defaultexp | | | delauth | | | delauthbyname | | | exportauths | | | exportstats | | | exportusers | | | moddb | | | zeroauth | +----------------+---------------+ |dbsetid | exportstats | +----------------+---------------+ |desc | addport | | | adduser | | | defaultport | | | defaultuser | | | moddb | +----------------+---------------+ |detail | moddb | +----------------+---------------+ |dformat | defaulteauth | | | defaultedb | | | defaulteport | | | defaultestat | | | defaulteuser | | | defaultexp | | | exportauths | | | exportdbs | | | exportpas | | | exportport | | | exportstats | | | exportusers | +----------------+---------------+ |disabled | addport | | | adduser | | | defaulteport | | | defaultexp | | | defaultport | | | defaultuser | | | exportport | +----------------+---------------+ |enabled | moddb | +----------------+---------------+ |enddate | defaultestat | | | defaultexp | | | exportstats | +----------------+---------------+ |exist | addport | | | adduser | | | defaultport | | | defaultuser | +----------------+---------------+ |expiry | addport | | | adduser | | | defaultport | | | defaultuser | +----------------+---------------+ |expirytd | adduser | +----------------+---------------+ |file | defaulteauth | | | defaultedb | | | defaulteport | | | defaultestat | | | defaulteuser | | | defaultexp | | | defaultprint | | | exportauths | | | exportdbs | | | exportpas | | | exportport | | | exportstats | | | exportusers | | | print | +----------------+---------------+ |format | defaulteauth | | | defaultedb | | | defaulteport | | | defaultestat | | | defaulteuser | | | defaultexp | | | exportauths | | | exportdbs | | | exportpas | | | exportport | | | exportstats | | | exportusers | +----------------+---------------+ |from | getfile | | | putfile | +----------------+---------------+ |iid | addport | | | adduser | | | defaultedb | | | defaultestat | | | defaulteuser | | | defaultexp | | | defaultport | | | defaultuser | | | delauth | | | deloldport | | | delport | | | deluser | | | exportdbs | | | exportstats | | | exportusers | +----------------+---------------+ |ipexcl | adduser | | | defaultuser | +----------------+---------------+ |ipincl | adduser | | | defaultuser | +----------------+---------------+ |maxcharge | adduser | | | defaultuser | | | moddb | +----------------+---------------+ |maxctime | moddb | +----------------+---------------+ |maxlogins | addport | | | adduser | | | defaulteport | | | defaultexp | | | defaultport | | | defaultuser | | | exportport | | | moddb | +----------------+---------------+ |maxrecs | defaultedb | | | defaultestat | | | defaulteuser | | | defaultexp | | | delauth | | | delauthbyname | | | exportdbs | | | exportstats | | | exportusers | +----------------+---------------+ |name | addport | | | adduser | | | defaulteport | | | defaulteuser | | | defaultexp | | | defaultport | | | defaultuser | | | delauthbyname | | | deldisable | | | delenable | | | deloldport | | | delport | | | deluser | | | disable | | | enable | | | exportpas | | | exportport | | | exportusers | | | getfile | | | login | | | moddb | | | portauth | | | portauthdel | | | putfile | | | server | +----------------+---------------+ |newfile | defaulteauth | | | defaultedb | | | defaulteport | | | defaultestat | | | defaulteuser | | | defaultexp | | | defaultprint | | | exportauths | | | exportdbs | | | exportpas | | | exportport | | | exportstats | | | exportusers | | | getfile | | | print | +----------------+---------------+ |noauth | moddb | +----------------+---------------+ |nodelete | adduser | +----------------+---------------+ |parent | addport | | | defaulteport | | | defaultexp | | | defaultport | | | exportport | +----------------+---------------+ |parentname | addport | | | defaulteport | | | defaultexp | | | defaultport | | | exportport | +----------------+---------------+ |password | adduser | | | defaultuser | | | login | +----------------+---------------+ |period | defaultestat | | | defaultexp | | | exportstats | | | moddb | +----------------+---------------+ |permission | adduser | | | defaultuser | +----------------+---------------+ |port | defaultestat | | | defaultexp | +----------------+---------------+ |portid | addport | | | defaulteport | | | defaultexp | | | defaultport | | | delauth | | | delport | | | exportpas | | | exportport | | | portauth | | | portauthdel | +----------------+---------------+ |portname | defaulteport | | | defaultexp | | | exportpas | | | exportport | | | portauth | | | portauthdel | +----------------+---------------+ |prodcode | addport | | | defaulteport | | | defaultexp | | | defaultport | | | exportport | +----------------+---------------+ |pswchanged | adduser | +----------------+---------------+ |pswlife | adduser | | | defaultuser | +----------------+---------------+ |public | moddb | +----------------+---------------+ |ref | adduser | | | defaultuser | +----------------+---------------+ |server | login | +----------------+---------------+ |sitename | addport | | | defaultport | +----------------+---------------+ |startdate | defaultestat | | | defaultexp | | | exportstats | +----------------+---------------+ |text | defaultprint | | | print | +----------------+---------------+ |to | getfile | | | putfile | +----------------+---------------+ |totcchrge | adduser | +----------------+---------------+ |totdchrge | adduser | +----------------+---------------+ |type | defaultexp | +----------------+---------------+ |updateseq | defaulteport | | | defaultexp | | | exportport | +----------------+---------------+ |userid | adduser | | | defaultestat | | | defaulteuser | | | defaultexp | | | defaultuser | | | delauth | | | deldisable | | | delenable | | | deluser | | | disable | | | enable | | | exportpas | | | exportstats | | | exportusers | | | getfile | | | portauth | | | portauthdel | | | putfile | +----------------+---------------+ |username | defaultestat | | | deluser | | | exportpas | | | getfile | | | portauth | | | portauthdel | | | putfile | +----------------+---------------+