The BKG Professional NtripCaster is meant for service providers handling several hundred incoming streams in support of thousand or more simultaneously listening clients. The BKG Professional NtripCaster software follows NTRIP Version 2. The main advantages over NTRIP Version 1.0 include:
Here is what you need to do to get the software up and running:
If you need detailed information about the program's setup and operation, have a look into files README and
INSTALL as well.
For any other technical questions please contact igs-ip@bkg.bund.de.
The recommended home directory for NtripCaster installation is /usr/local/ntripcaster. Below this home directory the sub-directories bin, conf, log, templates and var can be found.
Sub-directory bin contains the:
You can start the NtripCaster using the command ./ntripcaster start.
You can
restart the NtripCaster using the command ./ntripcaster restart.
You can stop the
NtripCaster using the command ./ntripcaster stop.
Note that casterwatch should never crash. In case ntripdaemon crashes or is shut down for re-configuration reasons, casterwatch shall restart it within a few seconds.
The NtripCaster’s home page is http://NtripCasterIP:Port/home.
The NtripCaster’s Administrator’s Web Interface is located at http://NtripCasterIP:Port/admin. Note that access to the Admin Web Interface is password protected. If port 80 is used, make sure that no other web servers are running on port 80 on the same machine.
Sub-directory templates contain templates for the Admin Web Interface http://NtripCasterIP:Port/admin as well as the NtripCaster’s home page http://NtripCasterIP:Port/home.
The essential parameters for running the NtripCaster are defined in ntripcaster.conf under sub-directory conf. Most of the parameters are self-explanatory. Note that neither ntripcaster.conf nor any other configuration file of the NtripCaster should be edited on a MS Windows system because this adds an extra ‘carriage return’ at the end of each record that may cause a problem.
For security reasons, however, we do not recommend using this generic password and instead recommend an identical procedure as for NTRIP Version 2.0 and to regulate the assignment of rights in the sourcecemounts.aut file.
The NtripCaster comes with an integrated NtripClient that lets you pull streams from other NtripCasters.
relay pull -i user:pass –m /PADO1 147.162.229.36:2101/PADO0
Explanation: A stream coming from mountpoint PADO0 on the remote NtripCaster 147.162.229.36:2101 is pulled using the user ID user and the password pass and made available on the local NtripCaster on mountpoint PADO1.
You might prefer to pull a stream directly from an IP address and port without using the NTRIP protocol. If this is the case, use the following command line in ntripcaster.conf:
relay pull –m /SYDN0 133.160.129.22:8000
Explanation: A stream from 133.160.129.22:8000 is pulled and made available on the local NtripCaster installation through mountpoint SYDN0.
The integrated NtripClient is using Ntrip version 1.0 protocol for communication and data transfer. For Ntrip version 2.0 usage please add "-2" as option.
Add the flag "-s" if the relay should use the TLS protocol. Setting this flag auto-enables the use of
Ntrip version 2. If your certifcates are not in the system default directory, a custom directory can
be set at compilation, see configure --help.
The directory must contain certificates in openssl directory format, see e.g. https://www.openssl.org/docs/man1.1.0/apps/c_rehash.html. See also Appendix TLS - Hints and Tips
You can specify a HTTP proxy with the parameter "-p host:port" (usually only for Ntrip version 2). This could be useful if your caster is running behind a firewall.
alias /FFMJ1 /FFMJ00DEU0
where FFMJ1 is the alias. Note that the alias mountpoints are neither visible in the sourcetable nor via web interface (sources or listeners), but can be seen in the casters log file ntripcaster-yymmdd.log. They can be used to smooth the renaming of mountpoints, e.g. for introducing the long RINEX3 mountpoint names, where the old mountpoint names should be kept for a while.
port 80
port 2101
deny all 11.22.333.44
deny all 111.222.*.*
All other IPs will have access in this example.allow all 141.74.*.*
Do not forget to add your own IP in this case! No other IPs will have access in this example.
read_timeout 30
The NtripClient authorization is configured through the files users.aut, groups.aut and clientmounts.aut under sub-directory conf.
soehne:wolfgang
stuerze:andrea
Yan:Thomas
ntrip:password
anderson:greg123
For (a) you would have to add an integer number at the end of a record in groups.aut. This integer number defines the maximum number of simultaneously listening clients from that group. Any additional client from that specific group denies access. No integer at the end of a record allows an unlimited number of simultaneously listening clients for that group.
For (b) the parameter specification max_ip_connections in ntripcaster.conf can be overruled by adding string “ip<n>” at the end of a record in groups.out, In this case <n> defines the maximum number of clients listening at a specific client IP address.
Following, we give examples for the three possible configuration record setups in groups.aut. Please, note here we suppose a max_ip_connections 5 configuration option in ntripcaster.conf.
/SYDNEY:bkg,gYan
/FFMJ0:unavco
default:OnlyMyOwnGroup
/admin:FirstAdmin,SecondAdmin,NTRIPAdmin
/oper:FirstAdmin,SecondAdmin
and thus mention FirstAdmin, SecondAdmin, and/or NTRIPAdmin as authorized groups to carry out
administrative/operational tasks. Note that you need to have operator rights to execute all commands
available for the NtripCaster operation because administrator rights are limited to a subset of
administration commands.
A taxi company in Sydney wants to enable each of its 100 drivers to receive a specific DGPS corrections stream through individual accounts. Since no more than 30 drivers are ever on duty at the same time, the company applied (and most likely paid) for access rights for a maximum of 30 concurrent clients only.
taxi1:password1
taxi2:password2
taxi3:password3
…
taxi100:password100
company:taxi1,taxi2,taxi3,…,taxi100:30
/SYDNEY:company
An NtripServer intending to occupy an existing mountpoint using the new NTRIP Version 2.0 protocol must have an account in users.aut defined as a member of a group of accounts in groups.aut which is authorized to use that mountpoint through a valid entry in sourcemounts.aut.
An NtripServer intending to occupy an existing mountpoint via NTRIP Version 1.0 must use either the generic encoder_password as defined in ntripcaster.conf or the password of a user who is a member of a group authorized by a valid entry in sourcemounts.aut. For security reasons, we recommend to enter an encoder_password in ntripcaster.conf that is difficult to decrypt and that you do not pass it on. Instead, we recommend that NTRIP Version 1.0 uploads should also be defined via explicitly entered user accounts, similar to NTRIP Version 2.0.
Please note: If no encoder_password is entered in ntripcaster.conf, the default password letmein , which is defined in the source code in the ntripcaster.h file, takes effect.
Example:
In users.aut we may have registered "provider1" (user ID) with password "password1" through:
provider1:password1
In groups.aut we may then configure provider1 as a member of group gupload through:
gupload:provider1,provider2,provider3,…
In sourcemounts.aut we may then allow the members of group gupload to upload a stream to mountpoint SYDNEY through:
/SYDNEY:gupload
In order to prevent an unauthorized upload to a not defined mountpoint, the keyword default may be used.
default:group1
In this example, group1 is allowed to upload data streams to any undefined mountpoints.The NtripCaster knows administrator and operator groups whose members perform administrative and operational duties and responsibilities through the Admin Web Interface http://NtripCasterIP:Port/admin. These groups are defined in groups.aut and receive their specific responsibility through the "admin" and "oper" admin-mountpoints in clientmounts.aut. The groups may be named FirstAdmin, SecondAdmin, and NTRIPAdmin.
FirstAdmin:Yan
SecondAdmin:soehne have unlimited rights on the
NtripCaster administration through the Admin Web Interface if these groups are part of the admin-mountpoint
oper in clientmounts.aut.
NTRIPAdmin:ntrip have limited rights concerning the NtripCaster
administration through the Admin Web Interface if this group is only part of the admin-mountpoint admin in
clientmounts.aut. They may use any Admin Web Interface command with the exception of command http://NtripCasterIP:Port/admin?mode=set.
telnet NtripCasterIP 2101
ADMIN [admin_password] where 2101 stands for the
NtripCaster’s listening port and admin_password is taken from ntripcaster.conf. Then press Enter twice.
Starting from NtripCaster 2.0.36, only about 4 seconds remain for entering the admin password before the software closes the connection.
You may now use any of the administration/operation commands described in Commands used with telnet:The execution of some of these commands requires operator rights. To become an operator, use the "oper" command: oper oper_password. Note that neither the admin_password nor the oper_password has anything to do with the passwords listed in users.aut. These two passwords are defined in ntripcaster.conf.
Note further that none of the configuration changes made through the Telnet admin commands are permanent! As soon as the NtripCaster is restarted, the contents of the basic configuration files becomes active again.
CAS;rtcm-ntrip.org;2101;NtripInfoCaster;BKG;0;DEU;50.12;8.69;http://rtcm-ntrip.org/home
Daily log files are saved under sub-directory logs. The NtripCaster maintains three types of log files:
access-yymmdd.log, ntripcaster-yymmdd.log and usage-yymmdd.log.
Note that files of type access-yymmdd.log follow the CSV format. You may like to upload these files to an external archive and by that rename its suffix to *.csv for read compatibility with the MS Excel program. The contents of these files may become the base for an accounting system.
Date,Time,User,IP,Station,Client,Seconds,Bytes
10/Aug/2007,20:42:31,hr,141.74.33.2,BURG0,NTRIP BNC 1.4,86,15166
10/Aug/2007,20:42:32,hr,141.74.33.2,MOBS1,NTRIP BNC 1.4,87,10873
...
The NtripCaster does not delete these daily log files. Check the disk space from time to time and delete them manually when necessary. Note that the size of the log files may become very large depending on parameter logfiledebuglevel defined in ntripcaster.conf.
The NtripCaster has no built-in support for TLS encryption but there exist several tools to add this functionality in form of a proxy server. One of them is stunnel.
The Apache HTTP Server offers this functionality as well but comes with a more complicated installation and configuration. This section has kindly been provided by Wim Aerts, Royal Observatory of Belgium. It guides you through setting up an Apache 2 HTTP Server instance to add SSL/TLS to your NtripCaster. It only deals with getting things to work, not with securing issues. For that the reader is referred to https://www.ssllabs.com/ssltest/index.html and relevant documents on that website.
Take the following steps:
<IfModule mod_ssl.c>
<VirtualHost _default_:443>
ProxyPreserveHost On
ProxyRequests Off
ProxyPass / http://localhost:2101/
ProxyPassReverse / http://localhost:2101/
SSLEngine On
SSLProtocol -all +SSLv3 +TLSv1
SSLCipherSuite TLSv1+HIGH:!SSLv2:!aNULL:!eNULL:
SSLOptions +StrictRequire
SSLCertificateFile /etc/ssl/certs/...
SSLCertificateKeyFile /etc/ssl/private/...
<Directory />
SSLRequireSSL
Allow from all
</Directory>
</VirtualHost>
</IfModule>
This should go somewhere in the Apache 2 HTTP Server configuration file(s). On Ubuntu it is placed in a separate file, e.g.: /etc/apache2/sites-available/mysite. Command a2ensite mysite will then 'enable' this 'available' site.
LDAP (Lightweight Directory Access Protocol) is a communication protocol for data exchange within a computer network that allows the request and modification of information provided by a directory service. Because LDAP is based on the client server principle it describes the communication between LDAP client and directory server. From such a directory that is realized as hierarchical database object-related data can be selected.
For data privacy reasons LDAP functionality is implemented for user authentication. Currently only simple LDAP access is supported. In case of LDAP usage usernames need to be added in normal configuration as well instead (e.g. simply add * as password in users.aut file), but for password checks LDAP is used: The NTRIP Caster, acting as LDAP client, formulates a request containing user name and password mentioned within the NTRIP client/server request and gets the answer “success” in case of congruence or “failure” otherwise from the LDAP server. LDAP authentication is normally disabled. It gets enabled when an LDAP server is specified in ntripcaster.conf:
ldap_server 127.0.0.1 Furthermore, the settings ldap_uid and ldap_people_context
in ntripcaster.conf are required for the LDAP request formulation:
ldap_uid_prefix uid
ldap_people_context ou=people The bind call is done
with '{prefix}={user},{context}'.
alias add <mountpoint> <newmountpoint>
alias del <mountpoint>
alias list
allow|deny <client|source|admin|all> add <hostmask>
allow|deny <client|source|admin|all> del <hostmask>
allow|deny <client|source|admin|all> list
Examples:
allow client add *.se
allow all del *.netcom.com
deny admin add *.se
deny admin del ap.*.com
allow admin list
Admin 341 <d66.ryd.student.liu.se> connected for 1 hours, 8 minutes and 14 seconds. 0 commands issued
A host-mask as an argument can be supplied, and only the admins who match the mask, will be shown.
admins <hostmask>
Example:
admins *.ifag.de
help [command]
Examples:
help kick
help
kick <id>
kick <-acs> <hostmask>
kick <hostmask>
Examples:
kick 314
kick -a *.com
kick *.badsource.com
listeners [hostmask]
Example:
listeners *.ifag.de
oper <operator password>
quit [message]
rehash [filename]
Example:
rehash /tmp/newrtcmast.conf
sources [hostmask] [-options]
The options are as follows:
i - Connection id
s - Socket descriptor
t - Time of connect
p - Connection ip
h - Hostname
c - Connection state
y - Source type
c - Number of clients
d - Dumpfile
r - Mountpoint priority
M - Source mountpoint
R - Bytes read
W - Show bytes written
C - Total client connects
T - Time connected
Example:
sources *.apan.com –aCW
set
set <variable name>
set <variable name> <new value>
Examples:
set client_timeout
set max_clients 580
stats [hourly|daily]
tell <message>
list [hostmask]
Example:
list *.toomanyarguments.com
relay pull [-s] [-2] [-i <userID:pass>] [-m <localmount>] <caster-URL>
Example:
relay pull -2 -i user1:password1 -m WTZR0 igs-ip.net:2101/WTZR00DEU0
auth <groups|users|mounts>
Example:
auth groups
auth users
configure --with-tls-certs-dir=</mycerts>
Certificates must be in individual files in .pem format. Each .pem file starts with a
line -----BEGIN CERTIFICATE----- and ends with line -----END CERTIFICATE-----.
OpenSSL expects the certificates with hashed file names. These hashed file names consist of a hash
obtained from OpenSSL, with a numerical extension starting at 0.
Syntax:
openssl x509 -hash -noout -in <mycert.pem>
A more convenient Example, generating hashed links for all .pem files in your directory:
for file in *.pem;do ln -s "$file" "$(openssl x509 -hash -noout -in "$file")".0; done
echo QUIT|openssl s_client -showcerts -connect igs-ip.net:443|awk '/-----BEGIN CERTIFICATE-----/ {p=1}; p; /-----END CERTIFICATE-----/ {p=0}' > <myfile.pem>