-
Notifications
You must be signed in to change notification settings - Fork 1
Remote installation
wxobs requires access to the weewx database to generate and display the pages you will see.
If you move your web pages to another server by using weewx's built in transfer routines, as found in weewx.conf...
[StdReport]
[[FTP]] # one method
[...]
[[RSYNC]] # another method
[...]
then wxobs will also be transferred. It is part of the weewx web directory so it will be transferred with the rest of it.
However, it won't be able to access the database because that does not get transferred by those same weewx FTP or RSYNC routines.
What we need to do is give that remote wxobs access to the database back at the original machine, or move the database to the same remote machine, server. We also need to move the php config file so that it picks up the change.
Before we set up any remote servers; you must get wxobs/index.php working locally. Once that is done you can go the next step and get it operating remotely.
Mysql can probably be done by rewriting the weewx/weewx.conf entry by replacing localhost with the address (DNS or IP) of that (localhost) machine. Or pointing it to a local slave installation of mysql (backup and convenience in one) I haven't done either of those options. If you do a mysql remote setup I'd be pleased to know how it goes, and will expand these notes accordingly.
Sqlite can be done with the remote branch (soon to be master) of weewx-wxobs. The skin.conf file has the config settings and a rudmentary overview. This page attempts to expand on those notes and tie it all together.
With a working installation of wxobs running with the sqlite database,
- We need to transfer the local database to the same location on the remote machine.
- We need to copy the local php include file to the same location on the remote machine. The location of this file can be changed if required, and if it's done through the settings in skin.conf .
- It's assumed you already have the local weewx web directory copied to it's equivalent location on the remote server. If you haven't, you need to set up that process first. If you use weewx's RSYNC you'll be performing the configuration stepd for password-less access and wxobs will benefit from that action, wxobs requires it as well.
sqlite is the default database type for a fresh install of weewx. If you've done nothing to change it, this is what you'll have.
An sqlite database can be simply copied to another destination (unlike a mysql setup) and should survive the disruption if there are no writes occuring while it's being done. wxobs can do that database copy operation during the report cycle when there will be no write operations to the database so all should go smoothly and a current, or updated, database will be available on the remote machine for the wxobs php file (wxobs/index.php) that has been transferred there, to use.
- We will use rsync, the program and it will be called by our report: wxobs
- Just as weewx uses the rsync program to perform its RSYNC report.
This is an essential requirement for rsync to be used to access a remote server unattended - as we are doing with our remote server access. If you are using the RSYNC feature in weewx already, then you will have iconfigured it already. We can use that user name for our transfer because i9t should have the required permissions. Especially if we change the database and include file locations to reside in the web directory. I'm assuming too, that we are sending to the same server.
If you haven't done it yet there are a few tutorials out there. Have a read of them and configure your user accordingly.
- SSH with authentication key instead of password
- How to set up ssh so you aren't asked for a password
READ WRITE : root@raspberrypi:~# ssh-keygen Generating public/private rsa key pair. Enter file in which to save the key (/root/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /root/.ssh/id_rsa. Your public key has been saved in /root/.ssh/id_rsa.pub. The key fingerprint is: e6:54:4e:43:b1:72:fb:8d:5f:3f:8c:d6:b4:2a:8b:fa root@raspberrypi The key's randomart image is: +---[RSA 2048]----+ | o. | | . . | | . * | | * o | | S o | | + . o . | | . o * o| | .. + *.| | .oE .+.o o| +-----------------+ READ WRITE : root@raspberrypi:~# ssh-copy-id -i ~/.ssh/id_rsa.pub graybeard@192.168.0.100 /usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed /usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys graybeard@192.168.0.100's password: Number of key(s) added: 1 Now try logging into the machine, with: "ssh 'graybeard@192.168.0.100'" and check to make sure that only the key(s) you wanted were added. READ WRITE : root@raspberrypi:~# ssh 'graybeard@192.168.0.100' The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. You have new mail. Last login: Tue Feb 14 08:56:07 2017 from 192.168.0.215 xterm graybeard@whitebeard:~ 09:31 AM $ logout Connection to 192.168.0.100 closed.
To set this up you need to edit the section in wxobs/skin.conf, which appears as follows (vers 0.6)
[[Remote]]
# This section is used ONLY if you wish to use wxobs on a remote machine
# where it cannot access the sqlite database.
# It is for the sql database only, mysql should be accesable by replacing
# hostname with the actual ip address (localhost)
# To allow it to run, it requires a valid entry for both values eg: -
#rsync_user = pi
#rsync_machine = 192.168.1.62
rsync_user =
rsync_machine =
#
# The option exists to move both the files to a single directory of your
# choosing. This should help if you have permission issues or limited
# access to the remote server. wxobs will attempt to create the directory
# if it doesn't exist.
# The default is to use the same as the local settings
# dest_directory =
#
# The option also exists to only send the include file once (in case you
# decide to manually configure it)
If either the rsync_user field OR the rsync_machine field is empty, no transfer can or will occur.
If you are not using sqlite, it doesn't matter what you have here, it will be silently ignored.
If you satisfy the above criteria, and have public key (password less) access configured between your database machine and the remote machine then the logs will show some information. Hopefully it will be a success.
If you wish you can reset the remote directory to be different to the local one (the defaults are /usr/share/php and /var/lib/ for the include file and database respectively.)
The logs will show more if you set wxobs_debug option in the skin.conf file, as follows
# debug output:
#
# wxobs_debug: Allow index.php to include debugging info if set to.
# 1 and above is low level, variables, some logic.
# 2 is for wxobs remote cmds etc.
# 3 only for delta-T final values (low level - if enabled)
# 4 only for delta-T unit conversion calcs (verbose) - if enabled
# 5 only for ordinalCompass conversion calcs (N, NE...CALM) (verbose)
# 6 is for database debugging
wxobs_debug = 2
with wxobs debug set to 2, public key access configured and writeable directories you should be greeted with something like...
[...]: wxobs: rsync cmd is ... ['rsync', '-ac', '--stats', '--compress', '/var/lib/weewx/sqlitedupe.sdb', 'pi@192.168.1.2:/var/lib/weewx']
[...]: wxobs: rsync'd 69,216 bytes bytes in 1 files (3,747,840 bytes) in 0.50 seconds
[...]: wxobs: rsync cmd is ... ['rsync', '-ac', '--stats', '--compress', '/tmp/wxobs_sqlitedupe.inc', 'pi@192.168.1.2:/tmp']
[...]: wxobs: rsync'd 153 bytes bytes in 1 files (153 bytes) in 0.29 seconds
The last line, the include file transfer, will become 0 on subsequent transfers because it never (or rarely) changes...
[...] wxobs: rsync'd 0 bytes bytes in 0 files (153 bytes) in 0.29 seconds
You probably won't get the above success on your first run and instead will get an error of some sort, the following is one that you will might see...
[...]: wxobs: rsync cmd is ... ['rsync', '-ac', '--stats', '--compress', '/etc/weewx/archive/sqlitedupe.sdb', 'pinochio@192.168.1.62:/etc/weewx/archive']
[...]: wxobs: ERR Permission error in rsync command, probably at remote end authentication ! FIX ME !·
[...]: wxobs: code 12, rsync failed, executed in 5.98 seconds to pi@192.168.1.2:/etc/weewx/archive
With this error we have changed the database location in weewx.conf (which is okay) but we don't have the same directory on the remote sever. The fix is to log in to the remote sever, add the directory /etc/weewx/archive and make it writable by the user.
[...]: wxobs: rsync cmd is ... ['rsync', '-ac', '--stats', '--compress', '/usr/share/php/wxobs_sqlitedupe.inc', 'pi@192.168.1.2:/usr/share/php']
[...]: wxobs: ERR Permission error in rsync command, probably at remote end authentication ! FIX ME !·
[...]: wxobs: code 12, rsync failed, executed in 0.28 seconds to pi@192.168.1.2:/usr/share/php
This states that a permission error has occurred and this is more than likely to be because the user pi, doesn't have permission to write to the /usr/share/php directory to place the config file for wxobs.inc
This file contains passwords for mysql (if you were using that), paths to the database for sqlite and additions to php (such as the inclusion of a timezone setting.)
If this error is occurring with the sqlite database, then the files location is not as critical. The information that's within it is fairly mundane. We don't expose passwords or the like and there is nothing in it that is not known, or easily found elsewhere.
For that reason it's location is less critical and it can be located somewhere else without ill effect - providing the web server can find it, and it's reasonably secure (notes above not withstanding). The webserver is a likely candidate If it's all on a local LAN then there are fewer security implications if you can trust your intranet users.
wxobs/skin.conf offers an option to change it...
[wxobs]
# This shouldn't need changing, but if it does then /tmp is a good
# starting point. This will most likely be used with remote servers
# using sqlite databases, see [Remote] below
include_path = '/tmp'
You could use /tmp or any other location that the webserver can access. If you don't mind that it becomes available on your webserver then select a path to it within weewx or one level up. ie; /var/www/html/weewx or /var/www/html
By default this is set to True, ie:- always send it.
If the include file is really giving you grief, and you want to stop sending it then the switch for the skin.conf file can be set by adding send_include = False. This will stop sending it. It's placement, and upkeep in its intended destination is then your responsibility.
You may want to do this if you want to keep it in the recommended location (by the PHP maintainers) which is as defined in the php.ini file, and where its data is most secure. If you're getting the permission errors on the rsync transfer and don't want to, or can't, change the permissions on the remote side then you can instead place the generated file into its location manually and then turn off the rsync transfer for that file.
If that file later disappears, or you change databases and need an updated include file then you'll have to replace it manually. But first you'll have to remember that you did it in the first place!
[[Remote]]
# This section is used ONLY if you wish to use wxobs on a remote machine
# where it cannot access the database.
# It is for the sql database only, mysql should be accesable by replacing
# hostname with the actual ip address (localhost)
# to run it requires a valid entry for both values eg: -
#rsync_user = pi
#rsync_machine = 192.168.1.2
#rsync_user =
#rsync_machine =
rsync_user = pi
rsync_machine = 192.168.1.2
send_include = False
If you save to a mysql database you may be able to access it from this remote machine by changing the weewx.conf section under
[DatabaseTypes]
[[MySQL]]
#host = localhost
host = ip_address_or_DNS_name of your weewx machine.
This will work if the remote machine can access that IP address or resolve the DNS entry. If it's all on a local LAN it should be workable (untested). If it's truly remote (in the cloud) and can't get past your firewall then it won't work and you'll need to get imaginative.