The Admin User Interface is an HTTP-based interface that sends REST commands to the server to update configurations, change settings, and retrieve statistics.
REST stands for REpresentational State Transfer which is a stateless communication method that in our case passes commands using HTTP GET, PUT, POST, and DELETE commands to resources within the Tigase server.
After navigating to the Admin WebUI you will see basic information about navigation. The panel itself consists of two main parts: * left navigation menu, which groups all configuration items into categories; * central, main configuration page displaying configuration options of the selected items.
Each configuration item has name (upper line) and associated component (lower line) as some features can be executed in the context of different component (for example
Update Item Configuration can be executed for VirtualHost Manager or ExternalConnection Manager)
Allows you to configure some of the servers settings, such as message of the day, welcome message or initialize shutdown of the cluster node.
This is a list of script examples that can be run and do menial functions for each component. They may not have particular value themselves, but are present to be used as reference when writing custom scripts. Get list of available commands is one script, that is present for every component that is active on the server, and as its title implies, will provide a list of all commands for that component. Lastly, the two scripts from the Scripting section of this guide. Generally, there is not much needed to see in this section.
This section has one simple command: to be able to send a mass message to all logged in users. There are three types of messages that can be sent from this section: - normal Messages will show as a pop-up in most clients. - headline Certain clients will take headline messages and insert them into MUC or chats between users, otherwise it will create a pop-up like normal messages. - chat Chat messages will open up a chat dialog with users.
This section contains a considerable list of options and settings affecting server functions.
This allows you to set a log file to track a specific user. Set the bare or full JID of the user you want to log, and a name of the files you wish the log to be written to. The files will be written in the root Tigase directory unless you give a directory like logs/filename. The log files will be named with a .0 extension and will be named .1, .2, .3 and so on as each file reaches 10MB by default. filename.0 will always be the most recent. Logging will start once the command has been issued, and cease once the server restarts.
Here you can add SSL certificates from PEM files to specific virtual hosts. Although Tigase can generate its own self-signed certificates, this will override any default certificates. The certificates cannot contain a passphrase, or be encrypted. Be sure that the contents contain both the certificate and private key data. You also have the option to save the certificate to disk, making the change permanent.
This section allows you to create a custom function for the eventbus component. These scripts can have the server conduct certain operations if set criteria are met. You may write the script in either Groovy or EMCAscript. Please see the eventbus section for more details.
You can write scripts for Groovy or ECMAScript to add to monitor tasks here. This only adds the script to available scripts however, you will need to run it from another prompt. Note that these scripts may only work with the monitor component.
This section allows you to add monitor scripts in Groovy while using a delay setting which will delay the start of the script.
Depending on whether you have any external components loaded or not, this may show. This allows you to add additional external components to the running instance of Tigase.
This allows you to add new virtual hosts to the XMPP server. A breakdown of the fields is as follows:
Here you can restrict users to be able to communicate on specific domains, this works similar to the domain filtering policy using the same rule sets. For more details, see Domain Based Packet Filtering section for rule details and specifics. Note that the changes may be made to multiple JIDs at the same time.
This section allows you to create a new node for the pubsub component. Here is a breakdown of the fields:
pubsub#node type: sets the type of node the the new node will be. Options include:
Specify the subscriber model: Choose what type of subscriber model will be used for this node. Options include:
Specify the Publisher model: Choose what type of publisher model will be used for this node. Options include:
When to send the last published item: This allows you to decide if and when the last published item to the node may be sent to newly subscribed users.
Whether to sort collection items by creation date or update time: options include
Here you may set the default configuration for any new pubsub node. These changes will be made for all future nodes, but will not affect currently active nodes.
This page allows admins to set the default configuration for any new MUC rooms that may be made on the server.
This removes a monitor task from the list of available monitor scripts. This action is not permanent as it will revert to initial settings on server restart.
Provides a space to remove a node from the server. It must be the full name of the node, and only one node can be removed at a time.
This page allows the logged in admin to delete all nodes from the associated vhost. This change is irreversible, be sure to read and check the box before submitting the command.
You can fix a users roster from this prompt. Fill out the bare JID of the user and the names you wish to add or remove from the roster. This will NOT edit a user’s roster, but rather compare client roster to database and fix any errors between them.
This does the same as the Fix User’s Roster, but can apply to users who may not be logged into the local vhost, but are logged into a clustered server.
As the title implies this gets a users' roster and displays it on screen. You can use a bare or full JID to get specific rosters.
Enables you to see the contents of any file in the tigase directory. By default you are in the root directory, if you wish to go into directory use the following format: logs/tigase.log.0
If you don’t want to type in the location of a configuration file, you can use this prompt to bring up the contents of either tigase.conf or config.tdsl.
Will output the current config.tdsl file, this includes any modifications made during the current server session.
This may be listed multiple times for different components, but this will do as the section suggest and list available commands for that particular component.
Here you can run a test with the pubsub component on any node to test functionality and proper settings for the node.
Will display any errors the server encounters in loading and running. Can be useful if you need to address any issues.
This space allows you to create a new command script that will work within the associated component. Note that under the hyperlinked title, there is a listing of muc.server.org or pubsub.server.org, use these to determine where the new command will operate.
This allows the setting of new custom OAuth credentials for the server, and you can also require the use of OAuth tokens for users when they login. This is a setting for the specific host you are logged into. If you are logged into xmpp1.domain.com, it will not affect settings for xmpp2.domain.com.
This allows a JID to be paired with a BOSH session before that user logs in, can reduce CPU use if you have a user that logs in via BOSH on a regular basis, or a web client that will regularly connect. You may also specify HOLD and WAIT integers to affect how BOSH operates with the associated JID.
This window allows you to not only test, but publish an item to the specified node. All fields must be filled in in order to avoid the server dropping an improperly formatted stanza.
This will load a tree of pubsub nodes in memory, it will not output anything as it is mainly for developer use.
This will force Tigase to rebuild databases for the pubsub component, this may be useful for pubsub subscribers who continue to get pushed events after they unsubscribe.
This will reload any vhosts that the server is running. This may be useful if one is disconnected or broken during runtime.
This will remove a running vhost from the server, you will be presented with a list to pick from.
Like new command script, take a look at the subheading to determine which component you want to remove the script from. Once there, select the command you wish to remove from the server. If remove from disk is selected, then the change will be permanent. Otherwise, the command will be removed until the next server restart.
Select from a list the listener script you wish to remove. This will only affect custom listener scripts added to the eventbus component.
This provides fields to remove a room from the MUC component. you may suggest an alternative room which will move occupants to the alternative room once the current one is removed.
Here you can retrieve items from PubSub nodes, this simulates the get IQ stanza from the pubsub component. - Service name - The address of the pubsub component. - Node name - Item node to retrieve items from. - Item ID - The item ID of the item you wish to retrieve. - Items Since - UTC timestamp to start search from: YYYY-MM-DDTHH:MM:SSZ
This will list any connections to other servers that are considered bad or stale. This will populate very rarely as Tigase automatically adjusts around clustered servers that go down. In the event a connection stays bad, it is recommended to reset those connections in the next space.
This will reset the connections with other servers that are considered bad and have shown up in the S2S Bad State Connections page.
This provides a space for an administrator to manually have a JID subscribe to a particular node.
Here you can unsubscribe users from a particular node. Users can be a comma separated list.
Typically you will see only one item for vhost-man, but some additional components (ie. ext) may provided them as well. They each have their own sections, but provide for a plethora of server options. Changes to the server are done in real time, and may not be permanent.
You will be presented with a list of domains that Tigase is currently hosting, you will be able to change settings for one domain at a time using this function. Once a domain is selected, you will be able to set or change the following settings:
This section allows admins to edit individual users rosters, although it provides similar functionality to fix users roster, this is designed for precision editing of a user roster.
Operation Type: What function will be performed?
Subscription type: The type of subscription stanza that will be sent to the server, and subsequently between the two users will be employed.
This section is an expanded version of the previous one, all fields already specified are the same with these additions:
This section will enable administrators to custom write or enter their own scripts for specific components. Each active component will have an entry for new and remove command scripts and scripts written there will be for that component.
As with New Command Script, there is an entry for each component. This page will provide a space to remove commands for the selected component. You will be provided a list of scripts associated with that component. You also have the open to remove from disk, which will permanently delete the script from the hard drive the server is on. If this is unchecked, the script will be unavailable until the next restart.
This section is more useful to test statistics scripts and components, as many of them produce very small amounts of information, however these may be collected by other components or scripts for a better information display.
Provides a script output of user statistics including how many active sessions are in use, number of packets used, specific connections and their packet usage and location. All resources will return individual stats along with IP addresses.
Provides a list of active users under the selected domain within the server. An active user is considered a user currently logged into the XMPP server.
Here you can add new users to any domain handled by vHosts, users are added to database immediately and are able to login. NOTE: You cannot bestow admin status to these users in this section.
This enables you to change the password of any user in the database. Although changes will take effect immediately, users currently logged in will not know the password has been changed until they try to log in again.
This removes the user or users (comma separated) from the database. The deleted users will be kicked from the server once submit is clicked.
This section allows admins to get information about a specific user including current connections as well as offline and online messages awaiting delivery.
This will display all registered users for the selected domain up to the number specified.