Registration Server Settings¶
The Registration Server Settings are configured using the XML file (RegServerSetup.xml) during the initial setup of the server. Afterwards, these settings can be changed in the Admin Console, via the Edit Settings page.
The names of the settings below are identical to the names of the tags in the XML configuration file.
Set to True to enable license administration via the Administration Console.
If you are using the Admin Console and have multiple providers using the registration server, then this value must be set to True.
To detect man in the middle attacks when sending API requests to your server, you can define a salt. The sender must do a MD5 hash of the content which will be send and add the salt to his request. The checksum will be send in the URL, so that the Registration Server can check if the content was modified during the transport. For details, look the API documentation. If the left empty during the initial installation, the setup script will create a checksum salt automatically.
Log file that tracks API requests issued by the Administration Console. This file needs to be owned and writeable by the apache user. (default: /var/log/td-adminconsole-api.log)
The Registration Server has an API interface, which uses a the XML-RPC interface (see http://en.wikipedia.org/wiki/XML-RPC for details). The API functions are described in the API documentation. Using this switch you can enable api call logging for all calls to the database (to help identify problems). The requests will be logged in the database td2apilog in the table TD2APIRequests.
If you connect a Hosting Service to your Registration Server, the clients will request a default storage account on a Hosting Service. Each user has one default storage account. It’s possible to add more storage accounts to users but only the default storage account can be retrieved by the clients. Enabling the AutoDistributeDepot will also distribute the other accounts which belongs to the user to a new client installation.
On startup and later on in intervals between 4 and 12 hours, the client will ask for new RegServerURLs using the balance call (if the value is empty, the RegServerURL is used instead). If more than one URL is returned, the client uses a round robin algorithm to send the request to all different servers. The first URL in the list is the URL which must be always available. This will be used as a fallback URL, if the others in the list fail.
Cache Interval in seconds. Changes in TD2Setting and TD2OwnerMeta will be reloaded after CacheIntervall expired.
The default poll interval for clients (in seconds) to look for new invitations on the Registration Server.
These settings are sent to all Clients after login. Settings specified for a Provider can override the values defined here.
One Provider/Distributor which is registered at the server must be the default Provider (this is normally the first provider). For more informations about the Provider concept, please have a look at Provider Concept.
TCP port of the HTTP proxy server to be used for Host Server API requests.
IP address or host name of the HTTP proxy server to be used for Host Server API requests.
Set to True if outgoing Host Server API requests must use a HTTP proxy. This requires setting HostProxyURL and HostProxyPort as well.
The path to the apaches htdocs directory. During the setup the script will move HTML pages which are necessary for activation and other functions to the right location. The path depends on your 4 letter Provider Code (see Provider Concept and HTML and EMail Templates for details)
Invitations will be stored on the server for a specified period of time. The default is 30 days (2592000 seconds). After that duration the server will automatically delete older invitations. If the value is to 0, invitations will never be deleted. Deletions are carried out by the background task described here: “Delete Old Messages”-Task.
Within 14 days after the first registration, the client will send an invitation for each created Space to the registration server for devices the user may install in future. See Invitation for future devices for a detailed description.
Each new installation by a user will create a new device in the database. If the user were to get a new PC, it would be installed as a new device, but the first device will remain in the Registration Server database even if the user no longer uses it. Invitations will only be send to devices which were active within the defined period. Please notice, that the device active timestamp will only be updated once a day. So, the value should not be less than one day (86400 seconds). The default value is 96 days (8294400 seconds).
In the case of a problem in the client, the client can upload its log files to a server. The log will be send to a PHP script. We recommend using our URL since in general it will only be possible for TeamDrive Systems GmbH to understand the log output. If you want to use your own log upload server, please contact TeamDrive Systems to get the upload script and receive further information to access log files.
The Registration Server is running in apache worker mode, which will start several threads within one apache process to answer the requests. Because PHP is not thread-safe, it might be not possible to use the same apache for log uploads. It depends on whether your linux distribution offers ZEND Thread Safety or uses the Fast CGI PHP configuration.
The name of the Master Registration Server in your TeamDrive Network.
For TeamDrive clients using the free version, the media URL is used to download new banners from the server, which are to be displayed.
It’s possible to send notifications to other Space members with the client. The notification URL will be used to send these notifications. Please use the same domain as in RegServerURL.
For an inital connection or later on the online test, the client will ping the PingURL. This will return a defined answer:
<?xml version='1.0' encoding='UTF-8' ?> <teamdrive> <intresult>0</intresult> </teamdrive>
back to the client, so that the client can check if he can reach the server, or if there is a proxy or an other gateway which require additional steps to get internet access. The PingURL can be located on another server and just requires a file ping.xml with the above content. Default should be the same domain as in RegServerURL,
This URL will be used by the client to open web pages in response to clicks within the client. The client will add different parameters to the URL, so that the same URL can be used to call different pages. The RedirectorURL will not open the expected target page directly, it will redirect the call to the right target page. Therefore it’s possible to change the URLs later in the admin console without changing the client. There are different target pages defined:
- ProviderInfoURL: Info page about available provider codes
- ForumURL: A link to a forum
- TutorialURL: Link to tutorials
- FAQURL: Link to FAQs
- TDPSOrderURL: Link to buy a license for a TDPS
- LicensePurchaseURL: Buy client licenses
- DownloadURL: A link to your client download page
These links could be changed using the admin console in the global settings for all provider or for each provider individual in the Provider settings (see Provider Settings).
Optional Reg Server API URL, used by the Administration Console (e.g. http://regserver.yourdomain.com/pbas/td2as/api/api.htm). Must be set, if HTTPS should be used for API communication or if a dedicated API server is used. If empty, it will be derived from RegServerURL.
This is the name of the Registration Server. The name must be unique within the TDNS network. The name must be defined together with TeamDrive Systems GmbH. The name can not be changed later on without reinstalling all clients.
This is the main URL which will be used by the Clients to register and interact with the Registration Server. This URL must always be reachable by the Clients to offer the services. If the URL is not longer valid the Clients have no possibility to reach the server again.
Timezone used for date functions in the Adminstration Console. Please ensure that the timezone is valid (see /usr/share/zoneinfo/ for available time zone information)! (default: Europe/Berlin)
Enables backward compatibility with TeamDrive 2 clients.
Each client registration will store the IP address which was used to register the client. In case of a hacked account, it may be possible to identify the source of the request. The default is 2592000 seconds (30 days) after which the IP will be removed. Other possible values are -1 (never store the value) or 0 (never delete it). All values greater than zero will be taken as seconds. The Delete Client IPs auto task as described in “Delete Client IPs”-Task must be enabled.
Each new Registration Server in the TDNS network will be added to the “TD2RegServerList” table and must be white listed manually. You can define an automatic whitelisting of new servers using this field.
This value will be used to activate the TDNS integration of the RegServer, so that the users of your Registration Server can invite users of other Registration Servers which are registered in the TDNS network. Each Registration Server in the TDNS needs a ServerID and a Checksum value which will be defined by TeamDrive Systems. Without these values your server can not communicate with the TDNS. The two values must later be set in the <TDNS> section for each Provider (see TDNS Settings (<TDNS> XML block)).
TCP Port of the HTTP proxy server to be used for submitting TDNS requests.
IP address or host name of the HTTP proxy to be used for submitting TDNS requests.
Set to True if outgoing TDNS requests must be sent via a proxy. This requires setting TDNSProxyURL and TDNSProxyPort as well.
The Clients will call this URL to retrieve update notifications about newer versions. The server will return a HTML file with update information which is then displayed in the client. Upon clicking update, the client will open a browser and direct the user to your download page. The update notification can be configured using the admin console (see Administrative Guide).
Set to $false if usernames should be case sensitive. By default usernames are case insensitive. Since case-sensitive usernames can be a security risk, this is the recommended setting.
As described in the SMTP protocol http://en.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol#SMTP_transport_example there will be communication between the SMTP client on the registration server and the SMTP server which will accept the email for delivery. To avoid spam classification the HELO command must match the servers FQDN. If this value is empty, the default hostname / IP address detection will be used which might get 127.0.0.1 instead of the hostname.
The sender header can be defined to avoid spam classification (see sender field description in: http://en.wikipedia.org/wiki/Email#Header_fields). This is necessary in case that the invitations between the users doesn’t match to the domain which will be used by the registration server. If this value is empty, only the from header will be used.
This is a security setting, since invitation mails can, potentially, also be used for spam mails from an user sent by your mail server. You can define how many mails the user can send per day.
This is the start path to the templates. Each Provider will have their own templates. During the setup, the files will be copied into a directory using your 4 letter Provider Code.
The IP or DNS name of the SMTP server. It must be a SMTP server which can receive sendmail requests without require an authentication.
Timeout parameter in seconds for sendmail requests
This setting will control, if the above InvitationEmailReplyTo will be used or the email of the user which sends the email.
If false, additional devices (after the first device was successfully activated) must be activated by an email. If true, additional devices are automatically activated. In this case the user will receive a notification mail instead of the activation mail.
If another system will handle the user data, email changes should be disabled for the client, to avoid differences between the two systems. You have to use the API functions to synchronize email changes in your system back to the Registration Server and the TeamDrive Client. To disable the dialogue in the client a modification in the client is also necessary.
This setting controls whether users can create new user accounts on the Registration Server. Disable this setting if your users were imported into the Registration Server or if direct access to an alternative authentication system is used. Client settings must be used to disable the registration panels on the Client.
Very similar to AllowEmailChangeInClient. If another system controls the user records, this should also be disabled. To disable the dialogue in the client there a modification in the client is also necessary.
You can define a minimum password length to be used by a user. The default value is 8 characters. This parameter will only be checked by the API, since the Clients only send an MD5 hash of the password, which can not be checked on server side. A password complexity check is not implemented at the moment.
You can define a minimum username length to be used by a user. The default value is 5 characters.
Whether the user email is unique so that not two different accounts could use the same email.
This value is only valid per Registration Server. Duplicate emails within the TDNS network are allowed.
Settings required for HTML pages¶
In this block are the settings for the HTML pages for the email activation and email change process defined.
The activation URL will be used to open a result page when the user clicks on the activation link to activate their account. A detailed description can be found in HTML and EMail Templates.
This will be the start directory below your apache htdocs document root. The complete URL will be generated from the code and will also include the Provider information.
Login Security Settings¶
The following settings control some security related features used by the Administration Console. They can only be changed via the Administration Console (Edit Settings -> LoginSecurity).
Log file that tracks failed login attempts. (default: /var/log/td-adminconsole-failedlogins.log)
The number of failed login attempts to a particular account within LoginMaxInterval before further login attempts are subjected to a delay. (default: 5)
Time interval used by LoginMaxAttempts, in minutes. (default: 60)
Period of idle time before you need to log in to the Admin Console again, in minutes. (default: 30)