text:
|Oracle® Beehive Administrator's Guide
Release 1 (1.4)
Part Number E13797-02
|View PDF
This module describes how to provision and manage user accounts and user groups in Oracle Beehive.
This module contains the following topics:
Introduction to Managing and Provisioning Users with Oracle Beehive
Oracle Beehive provides a flexible user account management and provisioning structure. You can manage user accounts from the command line, or by using a third-party user management product such as an external LDAP directory.
Every unique user account in Oracle Beehive has a corresponding record in the Oracle Beehive database, even when users are managed (mastered) by an external user management product. The Oracle Beehive user account stores settings and parameters necessary to establish permissions and access to the various Oracle Beehive services and user functions. Oracle Beehive automatically synchronizes information when it is duplicated between an external user management product and the Beehive account profile.
Oracle Beehive user accounts can be mastered in either the Oracle Beehive database, or an external LDAP-based directory. "Mastered" means that source is used as the point of reference to determine the correct value for some user account attributes, and the master source is used for making changes to those account details. When user accounts are mastered in an external directory, Oracle Beehive automatically updates the Oracle Beehive database entry whenever account information in the external directory changes.
When a user account is mastered in an external LDAP-based directory:
Some attributes which are not in the LDAP-based directory may still be mastered in Oracle Beehive
LDAP-mastered attributes cannot be managed in Oracle Beehive. Changes to those attributes must be made in the LDAP-based directory
Once LDAP-based directory synchronization is enabled, you cannot add or remove users from Oracle Beehive. You may only add or remove users via the external LDAP-based directory. These user accounts will then be created or removed in Oracle Beehive during the automated synchronization process
For more information about setting up and managing Oracle Beehive with an external user management product, see "Integrating and Synchronizing LDAP with Oracle Beehive" in the Oracle Beehive Installation Guide for your platform.
This section contains the following topics:
The User Directory Service (UDS) is the Oracle Beehive service responsible for storing and retrieving user and group information, as well as contact lists (address books). All other Oracle Beehive services query UDS whenever they need to look up user or group data.
The Authentication Service interfaces with UDS during any authentication event to query the user login ID. Passwords are encrypted and stored by the Authentication Service. When users are mastered in an external, LDAP-based directory, the Authentication Service queries both UDS and the external directory for login information, but only the external directory stores the user password information.
All Oracle Beehive installations have an organizational structure rooted at the enterprise level. (In Oracle Beehive Release 1, each installation may only have one enterprise). However you can further structure your users into organizations. An enterprise may have any number of organizations, and each organization may have sub-organizations. You may create users within the root enterprise, or within an organization.
Note that adding a user to one organization does not prevent that user from interacting with members of a different organization.
Every Oracle Beehive user automatically has one personal workspace, created at account creation.
When an account is created, a personal workspace template is used during personal workspace creation. The personal workspace template contains details of the users' default folders, default seeded content, and seeded sensitivities. Service-specific folders are always created in the personal workspace. You can modify the default personal workspace template, and create custom personal workspace templates, to suit your requirements.
For more information about creating and modifying workspace templates, see "Managing Oracle Beehive Workspaces".
Policies are collections of "if ... then" logical statements which define how the Beehive system should behave, given certain inputs or circumstances. When you create or delete user accounts, the user provisioning or deprovisioning policies are triggered.
Oracle Beehive is shipped with a default provisioning policy. The default provisioning policy determines which personal workspace template should be used. By default there is only one personal workspace template. The default personal workspace template enables all Oracle Beehive services for all users.
You can modify the default provisioning policy, to customize and extend Beehive's automation with regards to user account management.
For example, if you create additional personal workspace templates, the policy can select which template to use, based on the value of a user attribute such as job title. If the new user is a vice president, one personal workspace template is used; if the new user is a software engineer, a different custom personal workspace template is used; and if the user has neither of these job titles, the default personal workspace template is used.
For more information about creating and managing policies, see "Managing Oracle Beehive Events, Policies, and Workflows".
beectl to Manage User Accounts
User account management functionality is exposed in the
command line tool. You can create user accounts, modify them, assign and change privileges, and delete accounts from the command line. The
commands for managing user accounts are provided, with full syntax reference in "Oracle Beehive Command-Line Utility", in the Oracle Beehive Administrator's Reference Guide.
There is a category of
commands, called "users". All of the
commands related to user and group management are in the users category. You can list these commands using the
beectl list_commands
beectl> list_commands --category users
Every user of Oracle Beehive must have a user account. Accounts have varying, highly-granular levels of access to Oracle Beehive services, clients, and stored artifacts. These features allow you to use Oracle Beehive user accounts to accommodate a wide variety of casual, limited, or regular users that will interact with Oracle Beehive in some way.
It is not necessary to create or use shared administration accounts in Oracle Beehive. Instead, each person may be assigned highly granular sets of permissions for performing administrative actions, as appropriate - up to and including total system access. Likewise, you can create user accounts with very limited access, such as for customers, contractors, or partners.
There are three types of people defined in Oracle Beehive:
These users by default have access to all services and objects of the Oracle Beehive system, based on the user's access privileges. Most Oracle Beehive users are Enterprise users.
These users are typically business partners or contractors, with limited access to the Oracle Beehive services based on access privileges.
External contacts cannot access any part of the Oracle Beehive system. The only purpose that this people-type serves is for their contact information to be accessible to users of the system in the enterprise global contacts list. External contacts do not have Oracle Beehive user accounts. You can add, modify, and delete external contacts in a manner similar to user accounts.
This section includes the following topics:
Oracle Beehive stores information about user accounts using five different types of account fields, referred to on the command-line as
Attribute: A general account field type. Attributes are usually text strings
Principal: An attribute used for authentication of the user. There must be one Primary Principal field for every Oracle Beehive user account, but there may be additional non-primary principal fields, including a voice principal (for use with voice mail systems) and a protocol principal (for use with protocols that only support 7-bit character sets)
Credential: a value that must be provided by a user in order to log in to Oracle Beehive, such as the password field. Each principal has a corresponding credential field
Address: A special attribute which combines a type (business, home, or other), a URI scheme, and a value. Address fields are special because Oracle Beehive can use them as destinations for messages, and can interpret the scheme to determine the correct transportation method for such a message
Property: This attribute includes the designation of the user as an extended-enterprise user, identification of a certificate, and a notes field. Additionally, if you create custom user attributes, they are designated as properties
Each of these account fields is described in greater detail later in this section.
Most user account fields are optional, but a few are required, meaning that every user account in Oracle Beehive must have a non-null value for the required account fields. Table 3-1, "Default User Account Fields" shows the default user account fields.
If the user will be using any Oracle Beehive e-mail functionality, you must enter an e-mail address (using the
--address option). It must be unique within the enterprise, and it must conform to the basic e-mail address format (firstname.lastname@example.com).
If the user will be using any Oracle Beehive instant messaging functionality, you must enter an IM address (using the
--address option). The IM address serves as a login under certain conditions. It must be unique within the enterprise, and it must conform to the basic e-mail address format (firstname.lastname@example.com).
When creating user accounts from the command line, in addition to providing user account fields, the
command requires you to specify a container for the user using the
beectl add_user
--scope option: the Enterprise, or optionally, an Organization within the enterprise. These are not user account fields; rather, they specify a Parent Identifier to which the user account belongs. The user will automatically have a membership to this parent identifier, but you can add additional memberships using the
--organization option.
For many account attributes, you can couple a value with a locale; this allows you to create different values for different locales. For example, you could create a family name for the en_US locale using common English spelling, and a different family name for the fr_FR locale using common French spelling. The following attributes support multiple locale values: family_name, given_name, display_name, middle_name, job_title, prefix, suffix, and nick_name.
Table 3-1 Default User Account Fields
|Required or Optional
|Field Type
All users must have a family name (surname, or last name). This value does not need to be unique. You can use any combination of alphabetic (including multi-byte) characters. If the familyname contains a space or any special characters, you must surround it with double quotes.
User accounts may optionally have a given (first) name. This value does not need to be unique. You can use any combination of alphanumeric characters. If the given name contains a space or any special characters, you must surround it with double quotes.
An alternative name to be used for display in various clients. This value does not need to be unique. You can use any combination of alphanumeric characters. If the display name contains a space or any special characters, you must surround it with double quotes.
An optional middle name. This value does not need to be unique. You can use any combination of alphanumeric characters. If the middle name contains a space or any special characters, you must surround it with double quotes.
A name prefix such as Mr., Mrs., or Dr.
A name suffix such as Jr. or Sr.
A nickname, such as Bob (for Robert)
Principal (Primary)
The value of this attribute is the exact string the user will normally enter when logging in to the system. It must be unique among all users in the enterprise.
Although inclusion of this attribute at account creation is not enforced, if it is null (not created), it is not possible to log in to Oracle Beehive with this account. Consequently, for practical purposes the loginid should be considered as mandatory for most accounts.
The password to be used for the first login to Oracle Beehive. After the first login the user can create a new password. User account creation will fail if the password value violates the password policy. By default, the Oracle Beehive password policy dictates that passwords must be at least 6 characters long, contain at least one capital letter, and contain at least one non-alphabetic character. If you are using
Although this attribute is required, it can be null (not created) if the Oracle Beehive password policy is modified to allow a zero-length password. By default, a password must be created for an account in accordance with the password policy.
A primary address designates an address that should be the default address for the user account. See "About User Account Addresses" for details on how to format an address.
An address is a composite attribute consisting of a type, a scheme, and a value. Addresses include phone numbers, e-mail addresses, street addresses, fax numbers, instant message IDs, and so forth. You can specify many addresses. See "About User Account Addresses" for details on how to format an address.
Addresses consist of a type, a scheme, and a value. This option lets you set an address that will be the default address for that type, for this user. See "About User Account Addresses" for details on how to format an address.
Addresses consist of a type, a scheme, and a value. This option lets you set an address that will be the default address for that scheme, for this user. See "About User Account Addresses" for details on how to format an address.
Address (Principal)
If the user will be using any Oracle Beehive voicemail functionality, you must enter a phone number. The phone number serves as a login to the voice mail feature under certain conditions, in combination with the PIN. It must be unique within this enterprise.
If you enter a phone number, and you will be using any Oracle Beehive voicemail functionality, you must enter an initial PIN. The user must enter the PIN when logging in to the voicemail feature. The user can change the PIN after the initial login. The PIN must conform to any PIN "password" policy currently active.
Because the primary principal may contain characters that are illegal with certain protocols (such as 7-bit e-mail protocols), you can use this field to enter a protocol-friendly alternate principal.
A password for the protocol principal. It must be compliant with the default password policy, and additionally should only contain 7-bit characters, to maintain compatibility with various protocols.
You may enter a time zone identifier corresponding to the user's home time zone. If you do not enter a value for --timezone, under most conditions Oracle Beehive will assume the user is in the time zone Etc/GMT. To get a list of valid time zone identifiers, use the
You may enter a locale identifier corresponding to the user's home locale. The locales should be in the format
A text field for specifying a job title.
A text field for specifying an office location.
A text field for specifying a company.
A text field for specifying a profession.
A text field for specifying a department.
You can enter the identifier of another Oracle Beehive user account, as this user's assistant.
You can enter the identifier of another Oracle Beehive user account, as this user's manager.
You can indicate whether this user has some e-mail messages routed to an external inbox, outside of Oracle Beehive. This attribute is not in versions of Oracle Beehive older than 1.3.
You can specify membership in additional organizations by entering the identifier of an Organization. You can specify multiple such memberships. Note: to specify that the user should be created at a given organization's scope, use the
You can specify that this user is an extended enterprise user using this attribute. This attribute is not available in versions of Oracle Beehive older than 1.3.
A special field for entering custom user account attributes, as well as notes, a user's encryption certificate, and a designation of the user as an extended-enterprise user. See "About User Account Properties" for details.
This section contains the following topics:
In Oracle Beehive, "principals" are globally-unique user names or identifiers, and "credentials" are passwords. You specify principals and credentials when creating or modifying user accounts, but while credentials are exposed (for adding or modifying) through the User Directory Service, they are handled and stored in a secure manner by the Authentication Service.
Principal is a field type, which is assigned to a user attribute. For example, by default (primary) principal is assigned to the login ID field.
Oracle Beehive user accounts must have at least one principal field (the primary principal), but it is possible to include additional principals in a user account.
The reason for supporting multiple principals is to allow a full range of acceptable characters for normal use in the primary principal, but include secondary (or "protocol") principals for protocols that only support a limited character set.
For example, if a user's name contains multi-byte characters, a secondary principal composed only of 7-bit characters allows the user to authenticate over the IMAP protocol. Another secondary principal composed only of numbers allows the user to authenticate with a voice mail system using a touch tone telephone; this is called the voice principal.
When you create a user using
, you use the
--login_id option to set the value for the primary principal.
A credential is a password for a given principal. The value of a credential field must conform to the password policy.
In Oracle Beehive, "addresses" are special user account fields designed to contain information that designates a destination for a message; an e-mail, a written letter, a telephone call, or a transfer of data via some other protocol.
Each address field is labeled according to a scheme that contains two parts:
Type: a label indicating the type of address (business, personal, other, or proxy), and a numeric value (1 through 5 for business, personal, and other; 1 through 25 for proxy)
Scheme: a value indicating a specific address (URI) scheme
An Oracle Beehive account may contain up to forty addresses of each scheme: five each of "business", "personal" and "other" addresses, and twenty five "proxy" addresses.
Table 3-2, "Oracle Beehive User Account Address Field Schemes" lists all of the valid schemes for an Oracle Beehive user account address field.
Table 3-2 Oracle Beehive User Account Address Field Schemes
File Transfer Protocol
Hypertext Transfer Protocol
Hypertext Transfer Protocol Secure
Instant Messaging
Instant Message Access Protocol
Lightweight Directory Access Protocol
Electronic mail address (e-mail)
USENET news
USENET news using NNTP access
Postal addresses, containing the following fields: <address-line-1><address-line-2><post-box-number><city><state><postal-code><country>
Session Initiation Protocol
Telephone number
Uniform Resource Names
Extensible Messaging and Presence Protocol
Note:Schemes beginning with "ora" are reserved for Oracle Beehive internal messaging functionality. For example, the ORAALERT scheme is used by Oracle Beehive for addressing alerts.
The following example demonstrates how to specify an Address and its value using the
command. In this example, a fax number is added to a preexisting user account:
beectl modify_user
beectl> modify_user --user login_id=user1 --address +business_1:FAX:6505551212
Note that you can use the
--address operator, the
--primary_address operator, the
--default_address_for_type operator, or the
--default_address_for_scheme operator.
In this case, a new business fax field is created, but is not designated as a primary address or default address for type or scheme. The type section specifies that it is
business_1; there could be up to five business fax fields, using types
business_1 through
The following example specifies the new attribute as the default address for type:
beectl> modify_user --user loginid=user1 --default_address_for_type +business_1:FAX:6505551212
By using the
--default_address_for_type operator, this value becomes the default
business_1 attribute, among all attribute types (phone numbers, e-mail addresses, and so forth).
The user account field type, "ATTRIBUTE", is the general type. While all user account fields may be commonly referred to as "attributes", those which are not Properties, Addresses, Principals, or Credentials, are Attributes.
Table 3-1, "Default User Account Fields" shows which user account fields have the ATTRIBUTE type, in the Type column.
The following attributes are stored as Properties:
extended_enterprise_user: A boolean value (true or false) which designates the account as an extended enterprise Oracle Beehive user if true, or a regular enterprise user if false.
certificate: an encryption certificate owned by the user, used when sending encrypted mails to that recipient
notes: a general-purpose text field
A property field has a name, value, and description. To add a property to a user account, use the
command with the
beectl modify_user
--property option:
beectl> modify_user --user login_id=user1 --property +name(is_external_user|certificate|notes)=value=description>
Use the
= (equal) character to separate the property name, value, and description.
You can also create new, custom user properties. This allows you to extend user accounts with your own attributes.
Use the
command to create a new custom user property:
beectl add_custom_user_property
beectl> add_custom_user_property --name <attribute_name> --type <property_type> [ --description <description> ]
--type is the field type that will be used for this custom property, such as integer, string, boolean, and so forth.
You can list all custom user properties using the
beectl list_custom_user_properties
beectl> list_custom_user_properties
A user account is a logical object in Oracle Beehive, essentially composed of a collection of required and optional data fields which are associated with each other. All entities, including user accounts, have a unique identifier, which is not normally displayed. However, user accounts also have a unique login ID. For most purposes in Oracle Beehive, whenever you need to identify a user account, you can use either the login ID or the identifier. You can use the
command to find the unique login identifier of any user account:
beectl list_users
beectl> list_users
This returns a list of users similar to the following:
----------------------------------------------- | Given name | Identifier | ----------------------------------------------- | Faruq | loginid=faruq_d | | BEEAdmin | loginid=beeadmin | | Sara | loginid=sara.jones | | Sarah Jane | loginid=sjparker | | Rajpal | loginid=rajpal.goyal | -----------------------------------------------
Each user is listed by first name, along with the unique user identifier, in the format
loginid=<login ID>.
If you delete a user account and then re-create it, even using identical information and user identifier as before, it will have a new internal (non-displayed) object identifier, and will not be accidentally or automatically associated with settings or data objects from the previous user account.
All users have at least one membership, to the enterprise or organization in which the user account was created. This is called the user account's context, and the containing enterprise or organization is called the Parent Identifier.
You can add additional memberships by using the
--organization option with the
beectl add_user
modify_user commands.
For example, a user named Fred Jones was created in the organization
orgn=Dev_QA,orgn=Dev,enpr=Oracle. Using the
command shows the following user account record:
beectl list_users --show_all_attributes
Display Record: 3 =========================================== User Identifier: loginid=fred.jones Family Name: Jones Given Name: Fred Display Name: Parent Identifier: orgn=Dev_QA,orgn=Dev,enpr=Oracle Middle Name: Job Title: Department: Company: Suffix: Prefix: Nickname: Profession: Office Location: Status: ENABLED External Inbox: false Effective External Inbox: false Extended Enterprise User: false Timezone: tmzn=Etc/GMT Principals =============== Principal Identifier: 13B2:6CCD:pcpl:F4AE2024BD5F4D1D9A7AC00C92AB964C000000000011 Principal Name: fred.jones Type: PRIMARY=true Addresses ============= Type: BUSINESS_1 Value: mailto:email@example.com Type: BUSINESS_1 Value: tel:16505551212 Memberships =================== Member Of: orgn=Dev_QA,orgn=Dev,enpr=Oracle Member Of: orgn=Dev,enpr=Oracle Member Of: enpr=Oracle
Note:This example shows results from Oracle Beehive version 1.3. Earlier versions of Oracle Beehive produce similar output, but with some different or missing attributes.
Since the user was created in a sub-organization called Dev_QA, which was contained by the Dev organization, which is in the Oracle enterprise, the user has three memberships: one to each of these parent levels of scope.
Using the
command with the
beectl modify_user
--organization option, an additional membership (to the organization Install_QA) is added:
beectl> modify_user --user loginid=fred.jones --organization orgn=Install_QA,enpr=Oracle
Now, listing the user shows that the Memberships have been updated:
Display Record: 3 =========================================== User Identifier: loginid=fred.jones Family Name: Jones Given Name: Fred Display Name: Parent Identifier: orgn=Dev_QA,orgn=Dev,enpr=Oracle Middle Name: Job Title: Department: Company: Suffix: Prefix: Nickname: Profession: Office Location: Status: ENABLED External Inbox: false Effective External Inbox: false Extended Enterprise User: false Timezone: tmzn=Etc/GMT Principals =============== Principal Identifier: 13B2:6CCD:pcpl:F4AE2024BD5F4D1D9A7AC00C92AB964C000000000011 Principal Name: fred.jones Type: PRIMARY=true Addresses ============= Type: BUSINESS_1 Value: mailto:email@example.com Type: BUSINESS_1 Value: tel:16505551212 Memberships =================== Member Of: orgn=Dev_QA,orgn=Dev,enpr=Oracle Member Of: orgn=Install_QA,enpr=Oracle Member Of: orgn=Dev,enpr=Oracle Member Of: enpr=Oracle
Note:This example shows results from Oracle Beehive version 1.3. Earlier versions of Oracle Beehive produce similar output, but with some different or missing attributes.
Similarly, you can remove memberships by using the
command with the
beectl modify_user
--remove_membership option:
beectl> modify_user --user loginid=fred.jones --remove_organization orgn=Install_QA,enpr=Oracle
The membership that was indicated is removed from the user account.
To facilitate the potentially highly-complex structure of user privileges in a large Oracle Beehive deployment, you may make use of roles. A role is a collection of privileges and access types designed to fit commonly-used user responsibilities or positions.
For example, a Business Administrator role might grant privileges to provision user accounts, manage various types of artifacts such as archived messages, conferences, and discussions, create and modify user groups, and so forth. This role might not provide access to functions such as shutting down or restarting services, changing memory allocation, or viewing system log files.
You may assign one or more roles to any user account. Roles grant privileges, but do not (by default) revoke them. In other words, if a user account is granted a privilege not granted by a role, assigning that account a role does not revoke the privilege. Roles do not interact with each other: a user has a privilege if any role grants it, and does not have a privilege only if no roles grant it (and it has not been granted directly to that user).
Likewise, you may later grant or revoke any privilege, regardless of whether that privilege is granted to a user account by any assigned role.
Oracle Beehive is shipped with a selection of pre-created roles designed to fit many commonly-used user and management functions. You can modify the supplied roles, use them as templates to design your own roles, or create new roles from scratch, to suit the requirements of your organization.
For more information about managing roles, see "Managing Roles", and "Managing Oracle Beehive Access Control".
By default, all user accounts are set to Enabled and Unlocked. You may Disable, Lock, or Delete a user account. Each of these states is treated specially by Oracle Beehive. When you Delete an account, the system behaves according to the appropriate deprovisioning policy.
If a user account fails authentication (the password entered is incorrect) more than the maximum number of attempts defined in the password policy, the affected principal of the account is automatically Locked.
When Oracle Beehive is installed and configured, a special user account is created automatically: the BEEadmin account. You can use this account to perform configuration tasks prior to creating your own user accounts. Once you have created at least one account with system administration privileges, you will usually not need to use the BEEadmin account.
Note:If you configure Oracle Beehive with an external, LDAP-based user directory, unless there is a BEEadmin account in that external directory which is marked to synchronize with Oracle Beehive, the BEEadmin account will be deleted when you first synchronize. This is because all Oracle Beehive accounts must be mastered in the external directory.
In addition to the BEEadmin account, when you act from the command line as the super-user, such as when you invoke
without logging in, objects may be indicated as owned by the "system actor". There is no user account related to the system actor, but it is a valid actor for the purpose of evaluating privileges. In this case, the system actor has the "BYPASS" privilege, allowing total access to all entities, objects, and functions of Oracle Beehive.
This section describes how to go about provisioning access to Oracle Beehive to your users. In the context of user accounts, "provisioning" means both creating an account, and the process by which the system enables users to access Oracle Beehive client functions. By default, a created account is automatically provisioned for access to all Oracle Beehive client functions.
The following sections describe user account creation and provisioning for both types of user accounts (enterprise and extended-enterprise). External users do not have user accounts; they are merely entries in various contacts lists.
The process for creating a user account depends on the nature of your deployment:
An "Oracle Beehive only" deployment, making no use of external user directory or coexistence.
A deployment where all user accounts are mastered in an external directory only; UDS synchronizes with the third-party LDAP-based directory server.
You may provision user accounts using the
command line tool. You may create user accounts one at a time, or in a batch process. To create user accounts in this manner, follow the instructions in "Provisioning User Accounts Using
beectl", or in "Bulk ProvisioningUser Accounts"
If you are going to use an external third-party LDAP-based directory server, you should set up synchronization before you create or provision any users. Follow the instructions in "Integrating and Synchronizing LDAP with Oracle Beehive" in the Oracle Beehive Installation Guide for your platform.
This section contains the following topics:
In a coexistence environment, such as with Oracle Beehive coexisting with Microsoft Exchange, you may grant access to Oracle Beehive services to Exchange users, provision users in both systems, or provision users only in Oracle Beehive but synchronize them with Microsoft Exchange. Before you follow any of the user account creation and provisioning instructions in this module, see "Configuring and Managing Oracle Collaboration Coexistence Gateway".
Note:This section describes how to create an Oracle Beehive user from the command line. Such a user is always mastered in UDS. If you are going to use an external, LDAP-based directory to master users, you should not create users in this manner. For instructions, see "Integrating and Synchronizing LDAP with Oracle Beehive," in the Oracle Beehive Installation Guide for your platform.
You can create a single user account, and provision it for Oracle Beehive, by using the
command. You can list the syntax by entering the following command:
beectl add_user
beectl> add_user --help
To create a user account for directory data mastered in UDS only, compose a
command containing the required and optional fields described in "About User Account Fields".
beectl add_user
You must also specify a level of scope, such as the enterprise or an organization. You can find the enterprise identifier by using the
beectl list_enterprises
beectl> list_enterprises
This will produce output similar to the following:
----------------------------------------------- | Enterprise Name | Identifier | ----------------------------------------------- | mycompany | enpr=mycompany | -----------------------------------------------
The identifier is the complete string "enpr=mycompany". You may find it convenient to copy this value to a text file for easy reference later.
You may also specify an organization as a user's scope. You can list organizations by using the
beectl list_organizations
beectl> list_organizations --scope <parent enterprise or organization> [--recurse TRUE|FALSE]
This will produce output similar to the following:
Organization name: ST Description: Unknown Identifier: orgn=ST,enpr=Oracle Allocated Quota: 0 Hard quota in megabytes (MB): Unlimited quota Default sub organization hard quota in megabytes (MB):Unlimited quota Default team workspace hard quota in megabytes (MB):Unlimited quota Default team workspace soft quota in megabytes (MB):Unlimited quota Default personal workspace hard quota in megabytes (MB):Unlimited quota Default personal workspace soft quota in megabytes (MB):Unlimited quota Active preference profile: prfp=ActivePreferenceProfile,orgn=ST,enpr=Oracle
Note:This example shows results from Oracle Beehive version 1.3. Earlier versions of Oracle Beehive produce similar output, but with some different or missing attributes.
In this example, an organization called ST is created under the parent enterprise; it has no limits set on quota.
Since organizations may be nested (an organization can contain organizations), you may use the
--recurse TRUE option to recursively list all sub-organizations within the scope you specify.
In additon to a scope, you must also (at a minimum) specify the user's
login_id, and
login_password attributes. Optionally you may specify many additional user account attributes.
Example 3-1 illustrates the syntax for a typical
command to add a single user to UDS. The example shows all of the mandatory attributes, along with a selection of optional attributes. Note that in this example, the password is obfuscated (instead of in plain text) because this command is being issued from
beectl add_user
command-line mode (instead of shell mode).
Example 3-1 Creating a single user using
./beectl add_user --family_name User1FamilyName --given_name User1GivenName --login_id firstname.lastname@example.com --login_password hioquery731419== --scope enpr=example --address BUSINESS_1:mailto:firstname.lastname@example.com --address BUSINESS_2:fax:121345222 --address BUSINESS_1:im:email@example.com --voice_principal 8881234567 --voice_pin 1234 --timezone tmzn=America/Denver --locale "en_us" --obfuscated
After you submit the command, the user account will be created. Submitting the command also triggers the provisioning policy, which determines how the user will be provisioned for Oracle Beehive. For more information about the provisioning policy, see "Managing Oracle Beehive Events, Policies, and Workflows".
The user should be able to log in to the system within a few minutes.
Rather than create user accounts one at a time, you can create multiple accounts at once, by passing an XML-formatted document to the
command. The XML standard format describes one or more user accounts, including, at a minimum, the required fields for each user. The file may also contain values for the optional fields. Creating many users at once using this method is referred to as bulk provisioning.
beectl add_user
The provisioning policy is triggered after the creation of each user account.
To bulk provision user accounts:
Create an XML-formatted file containing the user account information.
Issue the
command, using the --file option to specify the XML-formatted file:
beectl add_user
beectl> add_user --file <yourfile.xml>
If the XML file contains one or more invalid user definitions, those user accounts will not be created. However, all valid user accounts will be created. You will see a completion message something like the following:
user23 failed: invalid initial_password attribute user54 failed: duplicate email address 2 users failed 554 users added succesfully.
You can fix the invalid user entries and submit the XML file again. User accounts which were already created will simply fail to be re-created (because duplicate entries already exist in UDS), and the user entries which you fixed will be created.
For your convenience, an example user definition XML file is included at the end of this chapter: see "Example Bulk User Provisioning XML File".
External contacts allow you to populate the enterprise Oracle Beehive shared address book with entries which are not user accounts. External contacts cannot log in to Oracle Beehive. You can create, modify, and delete external contacts using
List all existing external contacts using the
beectl list_external_contact
beectl> list_external_contacts --show <show attributes(ALL|MORE)>
--show option allows you to specify the level of detail of each listed external contact will be displayed.
You can also list a specific contact using the
--contact <identifier of external contact > option.
You can locate a set of contacts with a common attribute value, by specifying one or more contact attributes. For example, list all contacts with a given department attribute:
beectl> list_external_contacts --department <department of the contact>
Create an external contact using the
beectl add_external_contact
beectl> add_external_contact --family_name <[locale:]family name>
As with user accounts, the family name field is required.
Note:As with user accounts, there are many optional fields you can use with external contacts. You can also preface most fields with a locale, used for display when an Oracle Beehive user is using a given locale setting for a client application. If you do not specify a locale, the default locale of
en_US is used.
Modify an existing external contact using the
beectl modify_external_contact
beectl> modify_external_contact { --contact <identifier of external contact> | --email <Email address of the contact> }
You can specify the external contact to be modified using either its identifier or one of its e-mail addresses.
Delete an external contact using the
beectl delete_external_contact
beectl> delete_external_contact { --contact <identifier of external contact > | --email <Email address of the contact> }
You can specify the external contact to be deleted using either its identifier or one of its e-mail addresses.
Note:You can send the
--purge command to purge a deleted external contact, in the same manner as purging user accounts. See "Deleting User Accounts" for more details about the
--purge command.
You may need to perform a number of one-time, periodic, and day-to-day tasks related to user accounts. This includes changing or resetting status, creating or modifying provisioning policies, modifying individual user accounts, managing large numbers of accounts at once, and creating, modifying, and deleting roles.
This section contains the following topics:
You have many options for listing and searching for user accounts in your enterprise.
To list all users, use the
beectl list_users
beectl> list_users
All users in the enterprise are listed, along with a summary of a few of their most commonly-referenced attributes.
You can list a specific user by specifying it with either the
--user option or the
beectl> list_users --user <user identifier> beectl> list_users --email <email address>
You can display a more detailed list of attributes by using the
--show option:
beectl> list_users --show [ALL|MORE]
Searching for Users
Note:Search paramaters for users are case-insensitive.
You can search for users matching a certain pattern, using the
--match (ANY|ALL) attribute with the
command, combined with one or more user attributes to match, from the following list:
beectl list_users
You may also indicate how much detail about each matching user to display, by using the the --show (ALL|MORE) option.
For example, to search for all users which were created at the level of a particular organization, and to display all attributes of each such user:
beectl> list_users --match ALL --organization <organization identifier> --show ALL
You can change the status of one or more user accounts manually, or the status of accounts may change automatically. For example, if a user makes repeated unsuccessful attempts to type in a password, the user account may be locked (depending on the password policy). Figure 3-1, "User account status flow" shows the life cycle of a user account, including all of the possible states of the account.
Figure 3-1 User account status flow
In this section, the behavior set by the default policy is described, but you may modify such behavior by creating or modifying the applicable policy.
For more information about user account policies, see "Managing Oracle Beehive Events, Policies, and Workflows".
When an account is locked (or unlocked), the locked status applies to the primary principal. For example, if a user exceeds the maximum number of failed login attempts using an IMAP client, then the IMAP Protocol Principal will be locked, but the user can still login to a voicemail system using their VOICE Principal.
To manually set a user account to enabled or disabled, use the
command to modify the principal, setting the desired status in the
beectl modify_user
--attribute_value parameter:
beectl> modify_user --status DISABLED --user loginid=user1
beectl> modify_user --status ENABLED --user loginid=user1
To lock or unlock (enable) a user account, use the following commands:
beectl> modify_user --user loginid=user1 --lock <principal to be locked(PRIMARY|PROTOCOL|VOICE|ALL)>
beectl> modify_user --user loginid=user1 --unlock <principal to be unlocked(PRIMARY|PROTOCOL|VOICE|ALL)>
To delete a user account, see Deleting User Accounts. You cannot set the MARKED_FOR_DELETE status; this status is set by the system when you send a user account delete command, or when a user mastered in an external LDAP-based directory is deleted from the directory (or no longer matches the query that marks a user for synchronization with Oracle Beehive).
The following account statuses are possible:
As soon as valid account creation values are passed in to Oracle Beehive and recorded in the database, the new account is set to created status. Oracle Beehive may still be performing provisioning functions, such as creating the personal workspace, adding the user account to other workspaces, and so forth.
In most cases you should not see the created status, and you cannot manually set an accout to created status.
When the process of provisioning the new account is completed, the user account status is set to enabled (by default), locked, or disabled status.
Most of the time, user accounts are set to enabled status. This means the user can log in to Oracle Beehive and make use of all provisioned services. By default, all user accounts are set to enabled when account creation and provisioning is completed. There is no explicit flag on an account called enabled: instead, a lack of other status flags means the account is enabled.
The lock/unlock mechanism is primarily intended to aid with enforcing authentication rules, such as a maximum number of failed login attempts rule. This prevents brute-force login attacks (password guessing) from succeeding.
When a user account becomes locked, all of the user's Principals are locked, so that the user can no longer log in to Oracle Beehive, even if the correct password is entered. In all other ways, the account continues to be treated normally; messages sent to the user will continue to be delivered to the user's inbox, the account name will continue to show up in address books, and so forth.
By default, a user account is set to locked status when the maximum number of failed login attempts is exceeded. This may occur if the user enters an invalid password repeatedly. The password policy sets the maximum number of failed login attempts. Depending on the password policy, an account may become locked temporarily (for a set period) or permanently (until unlocked directly by an administrator). You can change this behavior by modifying the password policy. For information about changing the password policy, see "Managing Oracle Beehive Events, Policies, and Workflows".
Administrators with sufficient privileges may also manually set a user account to locked status.
By default, manual action by an administrator is required to unlock a user account (by modifying the account and passing the
--unlock option). You could create a custom workflow that is triggered whenever an account is set to locked status, to automate the unlocking of user accounts. For information about creating custom workflows, see "Managing Oracle Beehive Events, Policies, and Workflows", and Oracle Beehive Application Developer's Guide.
When a user account is set to disabled status, the user cannot log in to Oracle Beehive. Additionally, the user account becomes unavailable to other users in the enterprise; it will no longer be listed in the enterprise contact list, messages sent to the user will be returned as undeliverable, and so on. Any artifacts owned by the user account continue to be owned.
The disabled status is useful for users who are only periodically allowed access to Oracle Beehive. You may also use the disabled status instead of deleting user accounts, such as when employees leave the company; this allows you to restore the account should the employee return to the company at a later date, with all previous stored artifacts and owned objects in place.
You may wish to create a custom policy or workflow that is triggered whenever a user account is set to disabled status, to determine the disposition of owned public workspaces, resources, and groups. For more information about creating custom policies, see "Managing Oracle Beehive Events, Policies, and Workflows".
The "marked for delete", "delete in progress", and "deleted" statuses are all set by the system when deleting user accounts.
Caution:The deletion of an account is unrecoverable, unless you resort to restoring the Oracle Beehive system from backup. For this reason, Oracle recommends that you use the disabled status when you want to remove a user from the system, only deleting the account after a verification process. Effectively the only difference between a disabled and deleted user is that you can easily set a disabled user back to enabled status.
When you initially begin the process of deleting an account (by issuing the
command), the user account is set to "marked for delete" status. At this point, the user deletion (deprovisioning) policy is triggered.
beectl delete_user
Once Oracle Beehive begins deleting the account, it is set to "delete in progress" status. This process is usually very fast, taking less than a second.
When the process is complete, the account is set to deleted status. Once an account is set to deleted status, it cannot be recovered. The user cannot be added to workspaces or calendar events, cannot receive messages, and will not show up in contact lists. However, all of the account's data remains stored in the system. This may be convenient for compliance and records retention purposes.
The removal of account data is resource-intensive. You can periodically run the
command with the
beectl delete_user
--purge option to purge accounts set to deleted status, and all their data, from the system. Oracle recommends running this command during minimum system usage periods, to avoid an impact on system performance during peak usage times.
Unlike a disabled account, when a user account is set to deleted, its unique user login identifier and and any other unique attribute values are released, so these values can be re-used by a new account. Any new account created with the same attributes will not be associated with data from the deleted account.
Note:When user accounts are mastered in an external, LDAP-based directory, a delete action is triggered by a corresponding account deletion in the LDAP directory. Whenever UDS reads a user account deletion from the LDAP directory, it will automatically set that account to "marked for delete" status and begin the deprovisioning process. As with UDS-mastered accounts, accounts mastered in an external LDAP directory that are deleted cannot be undeleted, and new accounts created with the same unique user attributes will not be associated with data from the previous, deleted account.
If you accidentally delete a user account, the only way to recover that account is to perform a system restore using a recent system backup archive.
For more information on deleting accounts, see "Deleting User Accounts".
In addition to the required and optional user account attributes provided by default in Oracle Beehive, you may create new attributes to suit the needs of your organization. You may create new optional or required attributes, or delete optional attributes.
modify_user is used to modify the values of custom properties. You use the
add_custom_user_property and
delete_custom_user_property commands for defining the properties themselves (that is, the metadata).
When you create a new user attribute, it is always of the type Property. Addresses and Principals are not considered custom attributes, even though by default, any specific address or principal field of an account might not be set.
To see a list of custom attributes, use the
beectl list_custom_user_properties
beectl> list_custom_user_properties
To create a new custom field, use the
beectl add_custom_user_property
beectl> add_custom_user_property --name <attribute_name> --type <property_type> [ --description <description> ]
<property_type>, valid options are BOOLEAN, COLLABID, DATETIME, DOUBLE, and STRING.
To delete a custom user property, use the
beectl delete_custom_user_property
beectl> delete_custom_user_property --name <name>
Whenever you change a user account's attributes, you are modifying that user's account. (When you make changes to group membership, you are actually modifying the group; the same is true of resources, workspaces, and so forth).
If a user account is mastered in UDS only, you can modify all of the user's attributes stored in Oracle Beehive.
For user account management for directory data mastered in an external directory (a third party directory server is synchronized with UDS), you should modify the account attributes directly in the external third party directory. When a user's attributes are modified in the third party directory server, a synchronization process is initiated with UDS and the user's attributes in the UDS directory will reflect the same modified attributes.
When a user account directory data is mastered in an external directory, but the attributes you want to modify are not stored by the external directory, you should modify those Oracle Beehive-specific attributes using Oracle Beehive.
To modify a user account in Oracle Beehive, use the
beectl modify_user
beectl> modify_user { --user <User Identifier> | --email <Email address of the user> }
You can provide the user identifier, or any of the user's e-mail addresses (addresses of scheme
mailto) to identify the user account you want to modify.
There are many user account attributes. See Table 3-1, "Default User Account Fields" for a complete list. See the
modify_user command reference for details and syntax.
For many user account attributes, mutiple values are permitted. For example, a user account can have multiple given names (for various different locales). If you want to remove or modify the value of a user account attribute which already has a value, you can use the
+ (plus) or
- (minus) signs. These signifiers work for all of the following attributes: family_name, given_name, display_name, middle_name, prefix, suffix, nick_name, property, address, login_id, voice_principal, and protocol_principal.
If you do not specify a
+ or
- option, the add action is assumed, and any existing value of the same attribut e will be overwritten.
interface will not allow an option value to begin with the
- (minus sign) character. As described in the
, you can use an alternate format to provide an option beginning with the
beectl --help
-; by prepending
ESCAPE: to the option text. For example:
beectl> modify_user --user loginid=user1 --nick_name ESCAPE:-Bob --nick_name +Rob
Roles are a useful tool for defining a common or shared level of privileges across an organization. For example, you may choose to grant a similar level of Oracle Beehive access to all of the vice-presidents in your company, or to all faculty at your university. You may define a role for a single user, a subset of users, or all users in your organization.
Roles are an intrinsic part of Oracle Beehive access control. See "Managing Oracle Beehive Access Control" for details about creating, modifying, and assigning roles to user accounts.
User account deletion is complex, because typically user accounts may have ownership of numerous artifacts, the disposition of which must be resolved before the user account can be fully erased from the system.
Note that, short of deletion, a user account may be locked, by setting it to locked status (temporarily removing the ability to log in), or disabled (removing access and removing the user from groups, preventing receipt of messages, and so forth). The difference between disabled and deleted is singular: a disabled account may be re-enabled, but a deleted account may not be undeleted.
For more information about user account statuses such as disabled and locked, see "About User Account Status". For instructions on changing user account status, see "Changing Status".
Caution:Oracle recommends making use of the disabled status when users leave your organization, reserving delete until some waiting period after they have left. This allows you to easily recover (by setting to enabled) any account in the event of an error, such as an incorrect user account being identified for deletion.
Deleting a user account does not delete data in the system, including user-owned data such as messages or files in the personal workspace. Such data remains in the system until you explicitly purge it. Purging user data is resource-intensive, so Oracle recommends you purge user data during a minimum-use period, such as late at night, to avoid causing a slowdown in system responsiveness.
When you delete a user account, you must either manually decide on the disposition of owned artifacts, or make use of a deprovisioning policy that automatically determines the disposition of owned artifacts according to policy rules. Ensure that all of a user's artifacts in Oracle Beehive are properly reassigned before purging the data.
For more information about managing artifacts, see "Managing Oracle Beehive Workspaces".
The procedure for deleting an account varies if you are using an external directory (a third-party LDAP-based directory server synchronized with UDS).
When deleting a user account mastered in UDS only, you can delete a user from UDS using
. When deleting a user account mastered in an external directory (a third-party directory server is synchronized with UDS), delete the account from the external directory server directly, using the external directory management tools.
beectl delete_user
Note:While a user account deleted in a third-party directory is automatically deleted by UDS, it is not purged. You must still manually purge the user, as in Step 5 below. Until you purge the user account data, a new user created in the external directory with the same user name or ID will fail to synchronize with UDS.
When a user account is deleted from a a synchronized external third-party user directory, UDS automatically responds by deleting the UDS user account.
Note:For OpenLDAP 2.4.X, UDS synchronization relies on the modifytimestamp field for user/group synchronization. This field is stored with each of the user/group entry in openldap. Using this field, Oracle Beehive can detect if the user is created/modified. However, when the user is deleted the entry is permanently removed from the openLDAP repository. Consequently, there is no way for UDS to discover that a user account has been removed.
To workaround this issue, you can periodically use the
command with the
beectl validate_directory_entry
--delete command to clean up Oracle Beehive and remove users that have been deleted from OpenLDAP:
beectl> validate_directory_entry --delete --profile openldapprofile --commit
You will see output similar to the following:
Total number of entries: 511 Number of entries to delete: 2 Number of successfully deleted entries: 2 Number of failed entries: 0
In this example, two user accounts in UDS were identified for deletion.
To manually delete a user account using
Set the user account to disabled status using the
beectl modify_user
beectl> modify_user { --user <User Identifier> | --email <Email address of the user> } --status DISABLED
Identify Oracle Beehive objects owned by the user, such as messages, groups, resources, folders, files, and workspaces, and dispose of them according to the requirements of your organization; by deleting, archiving, or reassigning ownership as appropriate. Commands useful for performing these actions include:
If there are any workflows currently requiring the attention of the user, you may need to cancel or modify each workflow. See "Managing Oracle Beehive Events, Policies, and Workflows" for details on how to modify existing workflows.
Delete the user account using the
command. You can specify the user using its unique user identifier, or its primary e-mail address:
beectl delete_user
beectl> delete_user { --user <user_identifier> | --email <user_email> }
At your convenience, purge user data, using the
command with the
beectl delete_user
--purge option. You may want to ensure that a system backup has taken place, to ensure rollback and recovery of user data is possible. Because purging is resource intensive, you should perform purge operations during a period of minimum system usage:
beectl> delete_user -{ --user <user_identifier> | --email <user_email> } --purge
Deleting external contacts follows the same procedure as outlined for user accounts, except that external contacts do not have a status, so you cannot disable them. Delete an external contact by issuing the
delete_external_contact command:
beectl> delete_external_contact { --contact <identifier of external contact > |--email <Email address of the contact> }
Then, purge the external contact data using the
--purge option:
beectl> delete_external_contact { --contact <identifier of external contact > |--email <Email address of the contact> } --purge
A group is a logical construct in Oracle Beehive. One or more users are members within the group, and one or more members may have group management privileges. Many groups are owned by a particular user, as well.
See Also:Group templates and XML examples are provided in "Oracle Beehive XML File Reference", in the Oracle Beehive Administrator's Reference Guide
This section contains the following topics:
Oracle Beehive allows you to create all manner of nesting and overlapping logical groupings of user accounts. As with user accounts, a group has a globally unique collabID, a unique identifier, and some optional fields.
Groups may contain sub-groups, users, and resources.
Groups can themselves be contained by the enterprise, an organization, another group, or a workspace. Groups may only contain members at the parent level of scope; for example, a group created within an organization may only contain members from that organization. Likewise, a group contained by a workspace may only contain members of that workspace.
Groups are useful because you can use them as an alias to perform various collaboration activities. For example, you can send messages to everyone in a group, invite everyone in a group to a meeting or event, broadcast an instant message to everyone in a group, and assign everyone in a group to a workspace. Groups are also useful for managing access control; you can grant or revoke privileges based on group membership, and you can use groups as specified actors when creating Access Control Entities (ACEs).
When a user account is assigned to a group, it normally inherits any attributes (access privileges) of that group.
You can define access privileges on a group level, and then assign user accounts to such a group, thereby granting those privileges to all members of the group. By default, a user is considered to be granted a privilege if either they are explicitly granted it (the privilege is granted directly to their user account) or implicitly granted it (the user is a member of a group which is granted the privilege, or has a role which grants that privilege).
See Also:For more information about managing access control, see "Managing Oracle Beehive Access Control".
You may create sub-groups within larger groups. There is no practical limit to how many nesting groups you may create. A user belonging to a sub-group is considered to also belong to any super-group that contains that sub-group.
A user account may belong to any number of groups.
Groups always have an owner. The owner of a group has privileges to add and remove membership of the group, as well as alter its editable fields. (Additional user accounts may be granted group management privileges as well.) When you create a group from the command line, you should usually add a user and assign ownership to that user. Until you do so, the owner of the group is the system actor, meaning, it can only be manipulated by the command line user.
When a user account is deleted, it is removed from all groups to which it formerly belonged. When a group is deleted, membership in that group is removed from all user accounts to which it applied. When a user account having ownership of a group is deleted, ownership of that group is either manually reassigned (the account is not deleted until all decisions are made, using a set of human workflows), or reassigned automatically based on the deprovisioning policy defined for Oracle Beehive.
Administration privileges for a group may be assigned on a per-group basis. In other words, a given user account may have administration privileges for only specific groups (at any level of super-group or sub-group), without gaining administrative privileges over any other groups. By default, the creator of a group gains administrative privileges only for that group (and all sub-groups contained by it). For more information about privileges, see "Managing Oracle Beehive Access Control".
You can also base privileges and roles on group membership. For example, you can grant Oracle Beehive administrative privileges to everyone in a Beehive Managers group. Or, you could assign everyone in such a group a role you created called the business-administrator role.
You can also use group membership as a variable when writing policies. For example, you could define a provisioning policy that grants extra personal workspace quota to members of the Maintenance group.
Note:The ALL_USERS group is a pre-seeded group created during Oracle Beehive installation. It automatically contains every user of Oracle Beehive. It is very useful for assigning privileges to all users, broadcasting messages to all users, and other such global operations. Do not delete the ALL_USERS group.
There are two types of groups:
Static groups
Dynamic groups
Static groups
A static group has an explicit list of members. Users must be directly added to the group, and directly removed from the group.
Dynamic groups
Dynamic groups have a membership defined by a query, so that users fitting whatever criteria is being queried are automatically made members of the group. The dynamic group query is based on any combination of user attributes, properties, or addresses.
For example, all users with a particular manager could belong to a dynamic group defined by a query agaisnt the Manager attribute of user accounts. Whenever a user's manager attribute is changed to that particular manager, that user is automatically added to the group. Likewise, whenever a user's manager attribute changes (the user switches to a different manager), that user is removed automatically from the group.
Note:Dynamic groups may also have individual users defined as members, by defining a query which returns a specific user account.
You can list all groups by using the
beectl list_groups
beectl> list_groups
You can list a specific group, using the
command with the
beectl list_groups
--group option:
beectl> list_groups --group <Identifier of the group>]
You can list the members of a group by using the
with the
beectl list_groups
--show MEMBERS option:
beectl> list_groups --group <Identifier of the group> --show MEMBERS
Searching for Groups
You can search for groups matching a certain pattern, using the
command with the
beectl list_groups
(ANY|ALL) option, combined with one or more group attributes to match from the following list:
Note:Search paramaters for groups are case-insensitive.
You may also indicate how much detail about each matching group to display, by using the the
--show (ALL|MORE|MEMBERS) option.
For example, to search for all groups which were created at the level of a particular organization, and to display all attributes of each such group:
beectl> list_groups --match ALL --organization <organization identifier> --show ALL
--show ALL option lists details for all members in the group, in addition to the group's description and status.
Administrators and privileged users may create any number of groups, and assign or invite users to them. As an administrator, you will probably create some base groups, and reassign ownership to various users, such as vice presidents or directors. Additionally, group creation privileges may be granted to some or all users. In this case, a user with group creation privileges may create any number of groups. Users may create public groups, which are listed publicly (all users can see that the group exists). Public groups require users to request membership from an approver.
Groups are nested, such that each group is a sub-group of some other context. Some groups are top-level groups, meaning they do not belong inside any other groups, but still belong inside the enterprise, an organization, or a workspace. Logically, all such groups also belong inside one enterprise-wide supergroup (the ALL_USERS group). Owners and those with administrative and group creation rights can create a sub-group inside any group which they control.
You can create or modify a group by creating an XML-formatted file that defines the group, and then importing the file from the command line.
When creating a static group, you can add specific users to a group by specifying them in the XML file (for static groups). For dynamic groups, users are added to the group according to the query criteria as soon as the group is created.
Note:In a static group template, users are specified in several ways, including by identifier and by e-mail address. Each user must only be specified once in a group template, however. Specify a user by any one method. For example, if you include both a user's identifier, and that user's e-mail address, group creation will fail.
To create a group, use the
beectl add_group
beectl> add_group --file <filename>
If the group is created successfully, you should see output something like:
Successfully added 1 groups. Failed to add 0 groups. Total groups 1
To modify a group, use the
beectl modify_group
beectl> modify_group --file <filename>
Note:When modifying a group, the XML file must specify the full group CollabID in the
group element.
Example XML-formatted files for group creation are provided in "Oracle Beehive XML File Reference", in the Oracle Beehive Administrator's Reference Guide.
To create a dynamic group, you first create an XML-formatted file, which contains the group creation information.
When creating dynamic groups, you can include one or more predicates, which define criteria for inclusion in the group. Each predicate specifies a single user account attribute, address, or property. In complex queries, predicates are linked using an operator.
This section includes the following topics:
Predicates including an account attribute use the following format:
<predicate> <attribute> <name>FAMILY_NAME</name> <value>Example%</value> </attribute> </predicate>
In this example, the attribute
FAMILY_NAME is used, and a value is entered in the
value element. User accounts with the
FAMILY_NAME value specified will be matched by the query.
The following user account attributes can be used in the
name child element of an
attribute parent element:
The names of the attributes are case-sensitive.
The MANAGER, ASSISTANT, TIME_ZONE, and ORGANIZATION attributes accept CollabID values only. Pattern-based searches of these fields is not available.
The content of the value element is the string that Oracle Beehive will attempt to match when performing the query.
Predicates including an address attribute use the following format:
<predicate> <address> <uri>scheme:value</uri> <type>type</type> </address> </predicate>
User account address fields contain the following three parts:
uri element contains the scheme and value of the address, separated by a
: (colon) character. The following schemes are available:
type element contains one of the following:
For BUSINESS, PERSONAL, and OTHER, X is an integer from 1 to 5. For PROXY, X is an integer from 1 to 25.
Predicates including an address attribute use the following format:
<predicate> <property> <name>exampleName</name> <value>exampleValue</value> </property> </predicate>
Properties are defined as name value pairs. The
name element can contain one of the following:
Note:The names of the properties are case sensitive.
You can use an exact string in the
value element of a query, but you can also use wildcards to match a pattern. Wildcards are formatted in the same manner as SQL LIKE wildcards. The wildcards
% (percent sign) and
_ (underscore) are allowed. The
% wildcard matches one or more characters, while the
_ wildcard matches exactly one character. Prefixing either wildcard symbol with a
\ (slash) character will cause it to be treated as a literal (not a wildcard) in a query.
For example, if the following values of
OFFICE_LOCATION exist: A15, A156, B156, B1568, and Main_12:
%15% will match A15, A156, B156, and B1568
A1_ will match A15
A15% will match A15 and A156
Main\_1% will match Main_12
Operators link predicates together into a complete query. You can perform a simple query with a single predicate by using
<operator type="NONE">, or you can perform a more advanced query by using
<operator type="AND"> or
<operator type="OR"> to assemble two or more predicates.
To create a single-predicate query, use the following format:
<operator type="NONE"> <predicate> . . . </predicate> </operator>
Place the predicate content into the predicate element.
To create a complex query with two or more predicates, use one of the following formats:
<operator type="AND"> <predicate> . . . </predicate> <predicate> . . . </predicate> </operator>
<operator type="OR"> <predicate> . . . </predicate> <predicate> . . . </predicate> </operator>
Nested predicates are supported up to any level.
The following examples demonstrate how to assemble a dynamic group query using one or more query predicates, linked by query operators.
Example 3-2 creates a dynamic group that includes all users whose office location is HQ.
Example 3-2 Dynamic Group Simple Attribute Query
<operator type="NONE"> <predicate> <attribute> <name>OFFICE_LOCATION</name> <value>HQ</value> </attribute> </predicate> </operator>
Example 3-3 creates a dynamic group that includes all users whose office location includes the string HQ.
Example 3-3 Dynamic Group Simple Attribute Query with Wildcards
<operator type="NONE"> <predicate> <attribute> <name>OFFICE_LOCATION</name> <value>%HQ%</value> </attribute> </predicate> </operator>
Example 3-4 creates a dynamic group that includes all users whose manager is a user with the specified CollabID.
Example 3-4 Dynamic Group Simple Attribute Query Using CollabIDs
<operator type="NONE"> <predicate> <attribute> <name>MANAGER</name> <value>6BAE:44D9:user:DCEDF8D6310B4AE69911C7607BBADBE4000000000000</value> </attribute> </predicate> </operator>
Example 3-5 creates a dynamic group that includes all users whose manager is a user with the specified CollabID, or whose office location includes the string HQ.
Example 3-5 Dynamic Group Complex Query
<operator type="OR"> <predicate> <attribute> <name>MANAGER</name> <value>6BAE:44D9:user:DCEDF8D6310B4AE69911C7607BBADBE4000000000000</value> </attribute> </predicate> <predicate> <attribute> <name>OFFICE_LOCATION</name> <value>%HQ%</value> </attribute> </predicate> </operator>
When a user is added to a group, by default that user is considered a member of all super-groups to which that group belongs. Since access control (aside from group privileges) may be based on group membership, it is important that conflicts in privileges are resolved properly.
For example, if a super-group called Development contains a sub-group called QA, members of the QA group are automatically granted privileges granted to the Development group. Any access control that allows access to members of the Development group, will by inference also allow access to members of the QA group. You could explicitly prevent such access, by granting access to members of Development only if they are not also members of the QA group.
By default, if a super-group grants a privilege, and a sub-group does not explicitly restrict it, members of the sub-group are granted the privilege.
You can override inheritance by explicitly granting or revoking privileges from a sub-group, or to individual members of the group.
For more information about access control, see "Managing Oracle Beehive Access Control".
This reference section contains example XML-formatted files for use in user management.
This is an example XML-formatted file for bulk user provisioning. This particular example contains three users. Refer to the XSD file for a complete definition. The XSD may be found at
You must change the collabIDs used in all
<scope> and
<membership> elements to match those of your enterprise or organization
Values for password elements must meet the default password policy requirements
If you include a password element for a given principal, you must order the elements as shown in the first user in the example: first the
<name> element, then the
<password> element, then the
<type> element
In the XML file, specify all extended enterprise users first, and then enterprise users.
Example 3-6 Bulk User Provisioning XML File
<?xml version = '1.0' encoding = 'UTF-8'?> <users xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <user> <scope> <cen>3BE6:6F48:enpr:363362FF3DA89B2EE040578C939A3A500000000001D0</cen> </scope> <user_type>EXTENDED_ENTERPRISE_USER</user_type> <familyname>Holmes</familyname> <givenname>Robert</givenname> <name>Robert</name> <principals> <add> <principal> <name>+16505551234</name> <password>8675309</password> <type>VOICE</type> </principal> </add> <add> <principal> <name>rholmes</name> <password>password</password> <type>PRIMARY</type> </principal> </add> </principals> <addresses> <add> <item> <address>TEL:+16505551234</address> <addresstype>BUSINESS_1</addresstype> </item> </add> <add> <item> <address>IM:email@example.com</address> <addresstype>BUSINESS_1</addresstype> </item> </add> <add> <item> <address>MAILTO:firstname.lastname@example.com</address> <addresstype>BUSINESS_1</addresstype> </item> </add> <add> <item> <address>TEL:+16505551444</address> <addresstype>PERSONAL_1</addresstype> </item> </add> </addresses> </user> <user> <scope> <cen>3BE6:6F48:enpr:363362FF3DA89B2EE040578C939A3A500000000001D0</cen> </scope> <memberships> <add> <item> <cen>3BE6:6F48:orgn:363362FF3DA89B2EE040578C939A3A5000000000076C</cen> </item> </add> </memberships> <user_type>ENTERPRISE_USER</user_type> <familyname>Langdown</familyname> <ou>Alpha</ou> <givenname>Mary</givenname> <name>Mary</name> <principals> <add> <principal> <name>+15145554321</name> <type>VOICE</type> </principal> </add> <add> <principal> <name>mary.langdown</name> <type>PRIMARY</type> </principal> </add> </principals> <addresses> <add> <item> <address>TEL:+15145554321</address> <addresstype>BUSINESS_1</addresstype> </item> </add> <add> <item> <address>IM:firstname.lastname@example.com</address> <addresstype>BUSINESS1</addresstype> </item> </add> <add> <item> <address>MAILTO:firstname.lastname@example.com</address> <addresstype>BUSINESS_1</addresstype> </item> </add> <add> <item> <address>TEL:+16505559876</address> <addresstype>PERSONAL_1</addresstype> </item> </add> </addresses> </user> <user> <scope> <cen>3BE6:6F48:enpr:363362FF3DA89B2EE040578C939A3A500000000001D0</cen> </scope> <memberships> <add> <item> <cen>3BE6:6F48:orgn:363362FF3DA89B2EE040578C939A3A5000000000076C</cen> </item> </add> </memberships> <user_type>ENTERPRISE_USER</user_type> <familyname>Tran</familyname> <ou>Alpha</ou> <givenname>Thanh</givenname> <name>mark</name> <principals> <add> <principal> <name>+16505556300</name> <type>VOICE</type> </principal> </add> <add> <principal> <name>thanh.tran</name> <password>Password2</password> <type>PRIMARY</type> </principal> </add> </principals> <addresses> <add> <item> <address>TEL:+16505556300</address> <addresstype>BUSINESS_1</addresstype> </item> </add> <add> <item> <address>IM:email@example.com</address> <addresstype>BUSINESS1</addresstype> </item> </add> <add> <item> <address>MAILTO:email@example.com</address> <addresstype>BUSINESS_1</addresstype> </item> </add> <add> <item> <address>TEL:+16505551454</address> <addresstype>PERSONAL_1</addresstype> </item> </add> </addresses> </user> </users>


text:
Russians protest against pension reform
Jump to navigation Jump to search
Tuesday, September 11, 2018
On Sunday, reportedly over a thousand Russians were arrested for illegally protesting against government plans for pension age adjustment. The protest spanned several regions across the country. The plan would raise the retirement age an additional five years, with new age for men at 65, for women at 60.
According to monitoring data from media project OVD-Info, 1018 people were arrested, including 452 people in St Petersburg, 183 people in Yekaterinburg, 60 in Krasnodar, 43 each in Moscow and Omsk, 23 in Perm, 22 in Kazan, 20 in Tver, 17 in Ufa, 15 in Habarovsk, 13 each in Tomsk and Belgorod, 12 each in Chelyabinsk and Lipetsk, 10 in Novosibirsk, and some 80 in other cities.
In Moscow, the rally started at Pushkin Square at 2 p.m. local time and anti-riot police pushed people away. They marched toward the Kremlin. On their way, they again clashed with Police and did not complete the route.
The protests reportedly started in the Far East and Siberia first, followed by western regions of the country.
Regional elections were also on Sunday.
The pension adjustment plan has reportedly coincided with a significant drop in approval rating of Russian President Vladimir Putin.
- "Russian police detain hundreds protesting against pension reform" — ABC News (Australia), September 10, 2018
- AP. "Protests against Putin's pension age proposals sweep Russia" — NBC News, September 10, 2018
- "Число задержанных на протестах против пенсионной реформы в России превысило тысячу" — BBC News Русская служба, September 10, 2018 (Russian)
- Sabra Ayres. "Protesters across Russia rally against Kremlin plan to raise retirement age" — NBC News, September 9, 2018
- "Russia pension protests: Police break up opposition rallies" — BBC News, September 9, 2018
- "Support for Russia's Ruling Party Slips in Regional Elections Amid Pension Protests" — The Moscow Times, September 9, 2018
March 17, 2012
Russian scholars call on Medvedev and Putin to defend Bhagavad Gita
Russian scholars call on Medvedev and Putin to defend Bhagavad Gita
Saturday, March 17, 2012
Twenty leading Russian scholars urged Russian President Dmitry Medvedev and Prime Minister, President-elect Vladimir Putin to step in and take the ongoing Bhagavad Gita trial in the Siberian city of Tomsk under "personal control", saying it "discredits Russia's cultural and democratic credentials in the eyes of the civilized world".
Last December, the Tomsk court rejected state prosecutor's indictment of the Bhagavad Gita As It Is, a commented translation of the ancient Hindu classic by the Hare Krishna founder Bhaktivedanta Swami, as an extremist text. However, in January the Tomsk prosecutor's office filed an appeal, arguing the commentaries incite "social hatred" and "violence against non-believers" and must be banned as "extremist". Tomsk region prosecutor Alexander Buksman publicly supported the appeal, saying that the proposed ban on the commentaries rather than on the Hindu text itself was justified, as "it's important to discern gems form the chatter in this very case". The appeal is scheduled for hearing on March 20.
In an open letter to the top Russian leaders, the group of eminent Russian scholars of philosophy, philology, and oriental studies strongly denounced the prosecutor's attempt to dismiss Bhaktivedanta Swami's commentaries as an extremist distortion of Bhagavad Gita itself, saying that these charges are "untrue and contrary to the traditions of Hinduism".
"The book does not contain any signs of extremism and does not incite hatred on ethnic, religious or any other grounds. On the contrary, the book written in the commentary tradition of Bengali Vaishnavism, one of the most popular branches of Hinduism, is considered sacred by a section of believers", the scholars emphasized, warning that the continued trial of the Hindu scripture in Russia is "driving a wedge in Russian-Indian relations." Similar concerns were voiced earlier at an all-Russian conference at Tomsk State University titled Bhagavad Gita in history and modern society, where scholars expressed perplexity at the prosecutor's move to declare a translation of the Hindu scripture extremist. Speaking at the conference, Irina Glushkova, chief researcher of the Indian Research Center at the Oriental Studies Institute of the Russian Academy of Sciences, stressed that "Bhagavad Gita As It Is has the right to exist as any other commentary or scripture. It is a fundamental principle of Hinduism and there is no any other Hinduism".
The controversial court case on the Bhagavad Gita, an ancient text regarded sacred by millions of Hindus, had already caused political and societal turmoil in India, with the Indian Parliament stalled over the proposed ban and Hindu activists burning Russian flags. The trial also evoked strong criticism from the Russian, Indian, and international media.
Related news
- "Russian court rejects move to ban Hindu scripture" — Wikinews, December 29, 2011
- "Indian Parliament irate as Russia poised to ban Bhagavad Gita" — Wikinews, December 20, 2011
Sister links
- Bhagavad Gita trial in Russia on Wikipedia.
- "Российские ученые просят Медведева и Путина взять процесс над "Бхагавад-гитой" под личный контроль" — NEWSru, March 15, 2012 (Russian)
- Vladimir Radyuhin. "Russian scholars' plea on Gita" — The Hindu, March 15, 2012
- "Bhagavad Gita case perplex scientists" — Russian Legal Information Agency, February 24, 2012
- PTI. "'Ban Gita' court battle restarts in Russia" — Zee News, February 17, 2012
- "Russia court declares Hindu book Bhagvad Gita legal" — BBC News Online, December 28, 2011
- Abhai Maurya. "Russians kick up an unholy row over holy book" — The Times of India, December 22, 2011
- March 17, 2012
December 29, 2011
Russian court rejects move to ban Hindu scripture
Russian court rejects move to ban Hindu scripture
Thursday, December 29, 2011
A judge in Tomsk, Russia drew a round of applause from the court room as she dismissed charges of extremism against the Bhagavad Gita As It Is, a Russian commented translation of the Bhagavad Gita published by the International Society for Krishna Consciousness. This decision put an end to the six-month-long trial of the book accused by the state prosecutors of fostering "social discord" and "incitement to religious hatred".
The Indian Foreign Ministry, which had been urging Moscow to avert the possible ban they termed as "absurd", welcomed the verdict calling it "a sensible resolution of a sensitive issue" which "demonstrates yet again that the people of India and Russia have a deep understanding of each other's cultures and will always reject any attempt to belittle our common civilizational values" and thanked the Russian government for their support. Indian Ambassador to Russia Ajai Mahotra also stated that the court decision "deserves to be applauded".
The controversial court case on the Bhagavad Gita, an ancient text regarded sacred by millions of Hindus, had threatened to become a stumbling block in traditionally strong Indo-Russian relations as it caused political and societal turmoil in India, with the Indian Parliament stalled over the proposed ban and Hindu activists burning Russian flags. The trial also evoked strong criticism from the international media.
Related news
- "Indian Parliament irate as Russia poised to ban Bhagavad Gita" — Wikinews, December 20, 2011
Sister links
- Bhagavad Gita trial in Russia on Wikipedia.
- "Russia court rejects plea to ban Gita" — The Times of India, December 29, 2011
- Preetika Rana. "Russia dismisses Bhagavad Gita ban" — The Wall Street Journal, December 28, 2011
- Dmitry Zaks. "Russian court rejects ban on Hindu sacred text" — Agence France-Presse, December 28, 2011
- "Russia court declares Hindu book Bhagvad Gita legal" — BBC News Online, December 28, 2011
- "Russian court rejects bid to ban Bhagavad Gita" — RIA Novosti, December 28, 2011
- Abhai Maurya. "Russians kick up an unholy row over holy book" — The Times of India, December 22, 2011
- December 29, 2011
December 20, 2011
Indian Parliament irate as Russia poised to ban Bhagavad Gita
Indian Parliament irate as Russia poised to ban Bhagavad Gita
Tuesday, December 20, 2011
Members of the Indian Parliament across party lines urged the Indian government to protect the Bhagavad Gita, one of the most sacred Hindu texts, from a legal ban in Russia.
Hindu followers rallied in front of the Kolkata Russian consulate protesting the ban. Thousands signed an on-line petition to stop the trial, and the hashtag #Gita surged to a leading trend in Indian cyberspace. Accused of fostering extremism and "social discord" by the Tomsk, Siberia state prosecutors office, Bhagavad Gita As It Is, a translation of the ancient poem admired by Leo Tolstoy and Albert Einstein, now faces the prospect of ending up on Russia's Federal List of Extremist Materials – along with Hitler's Mein Kampf – and being banned from distribution.
Reporting to the Parliament on the issue, External Affairs Minister S. M. Krishna Tuesday denounced the trial as a "patently absurd" action of "some ignorant and misdirected or motivated individuals" and assured the House that his Ministry has taken up the issue with senior Russian authorities, hoping for an appropriate resolution. S. M. Krishna also referred to the Gita as "one of the defining treatises of Indian thought" saying that it "describes the very soul of our great civilization".
On a similar note, Russian Ambassador to India Alexandr Kadakin condemned the court case as "categorically inadmissible" and called its instigators "madmen".
The court's ruling on the matter is expected on December 28.
- "SM Krishna's statement in Lok Sabha on Gita controversy in Russia" — NDTV, December 20, 2011
- IANS. "Gita controversy: Russia expresses sadness" — The Hindu, December 20, 2011
- "Russia criticism of Gita absurd, says India minister" — BBC News Online, December 20, 2011
- Tarun Vijay. "Political unity over Gita: A historic day in our times" — The Economic Times, December 20, 2011
- Nigam Prusty. "Hold India uproar at call in Russia to ban Hindu holy book" — Reuters, December 19, 2011
- IANS. "LS adjourned over Bhagvad Gita ban in Russia" — Hindustan Times, December 19, 2011
- IANS. "Bhagavad Gita faces 'extremist' branding, ban in Russia" — The Times of India, December 17, 2011
- Alexander Bratersky. "Krishna holy book faces ban in Tomsk" — The Moscow Times, November 29, 2011
Sister links
- Bhagavad Gita trial in Russia on Wikipedia.
- Bhagavad-Gītā As It Is on Wikipedia.
- December 20, 2011
January 22, 2010
Russian journalist beaten by police officer dies
Russian journalist beaten by police officer dies
Friday, January 22, 2010
A middle-aged Russian journalist in Tomsk, Siberia, died Wednesday. He succumbed to injuries suffered when a young police officer allegedly beat him into a coma earlier in the month while in a holding cell reserved for the drunk and disorderly. The injuries included severe damage to many of his internal organs.
Authorities identified this little-known reporter who specialized in economics as Konstantin Popov. Popov was one of the cofounders of a small regional newspaper publisher and a local magazine called Tema. In a country where police brutality and corruption—especially against journalists—is not uncommon, the editor-in-chief of Tema, Konstantin Karpachyov, said it was unlikely Popov's murder was in any way related to his work.
However, Karpachyov went on to say that, "This could happen to absolutely anyone. It demonstrates the police terror is aimed against everybody."
"The only thing different about this case is that he happened to be a journalist, so it became a high-profile public case. But the same thing happens every day," said Svetlana Gannushkina, of Russia's Civic Assistance committee. "Usually the cases are just closed down because there's no evidence, nobody testifies, and it's impossible to get to the bottom of it."
Upon learning Popov's identity, numerous members of the state-controlled media strongly criticized the police for their passive response to the actions allegedly committed by one of their own. Following which, news conferences were called, and before long Popov's case began to draw national attention.
This resulted in the holding cell where Popov's beating occurred being closed down. In addition, the deputy police chief resigned as well as supervisor of the precinct in question. The Tomsk police chief apologized. The suspected officer, Alexei Mitayev, was dismissed from the force, arrested, and is said to have since confessed to this crime. Mitayev cited that "stress due to family problems" is what led to his actions against Popov.
The chairman of the Tomsk branch of the Union of Journalists of Russia said that a source close to the investigation told him that Popov was not only beaten but was also "tortured" and "violated" with a foreign object.
"Hands off journalists!" the journalist union said in a statement on its website. According to the United States-based Committee to Protect Journalists, as far as they know, "since 2000, at least seventeen Russian journalists have been killed due to their work, and the killers have been convicted in only one case."
President Dmitry Medvedev said that such police misconduct was not only angering the Russian public, but was also undermining the state's authority. He called for comprehensive reform and ordered the Interior Ministry to cut its staff by one-fifth by 2012.
- Steve Gutterman. "Russian journalist dies after police beating" — Reuters, January 20, 2010
- Megan K. Stack. "Russian journalist dies after beating by police officer" — Los Angeles Times.com, January 20, 2010
- January 22, 2010
August 11, 2005
Scientists warn thawing Siberia may trigger global meltdown
Scientists warn thawing Siberia may trigger global meltdown
Thursday, August 11, 2005
Russian researchers warn that Western Siberia has begun to thaw as a result of global warming. The frozen peat bogs in this region may hold billions of tons of methane gas, which may be released into the atmosphere. Methane is a greenhouse gas 22 times more powerful than carbon dioxide.
Sergei Kirpotin, of Tomsk State University warned New Scientist that the event is an "ecological landslide that is probably irreversible and is undoubtedly connected to climatic warming".
David Viner, of the University of East Anglia told The Guardian: "When you start messing around with these natural systems, you can end up in situations where it's unstoppable". He also warns that this event was not considered by the Intergovernmental Panel on Climate Change.
In May, scientists from the University of Alaska found methane "hotspots" in eastern Siberia where the gas bubbles out from thawing permafrost bogs at a rate that prevents the surface from freezing.
The permafrost has been intact for 11,000 years and started melting 3 to 4 years ago, according to Kirpotin.
- Ian Sample. "Warming hits 'tipping point'" — The Guardian, Aug 11 2005
- "Siberia's rapid thaw causes alarm" — BBC News, Aug 11 2005
- "Permafrost Melt Heightens Climate Change Fears" — Friends of the Earth, Aug 11 2005
- "Thawing peat bog could speed global warming" — ITN, August 11, 2005
- Fred Pearce. "Climate warning as Siberia melts" — New Scientist, August 11, 2005
|The text of this article has been released into the public domain. In the event that this is not legally possible, this article may be used for any purpose, without any condition, unless such conditions are required by law. This applies worldwide. Copyright terms on images, however, may vary, so please check individual image pages prior to duplication.
Please note that this only applies to Wikinews content created prior to September 25, 2005. All content created after that date is released under a Creative Commons license which is mentioned at the bottom of each article. This is currently the Creative Commons Attribution 2.5 License.
- August 11, 2005

subset: commoncrawl