StreetSign Admin’s guide¶
Here’s first a guide on how to set up streetsign to play with. For full proper deployment (for real live production usage) check the Deploying Streetsign in Production page.
StreetSign requires python 2.7, imagemagick (to generate thumbnails). If you
are installing on a fresh server, you may need to install
python27-dev or whatever your distribution calls it.
(On a stock OSX computer, it doesn’t need anything.)
Once you’ve cloned or otherwise downloaded StreetSign and put it where you want it to be, you need to run the setup script:
which will create a python virtualenv in
.virtualenv, and install all the
libraries and other requirements into there.
To run the server in ‘production mode’ you can use the built in
waitress web server:
Which will spin up a version which should be totally capable for small deployments (up to a hundred screens or so, I guess). If you are going to be on a public network, then it’s advised that you run streetsign - either with waitress or another WSGI server of your choice - behind nginx or another reverse proxy, which should keep things a bit saner. If you’re on a public network, also remember to set up your reverse proxy to use SSL, so that you aren’t sending log-in credentials around in plaintext.
If you want to run anther WSGI server, remember the virtualenv that streetsign
is using, so any scripts you write need to use the python found in there
.virtualenv/bin/python). You can use pip from in there to install any
pypi packages you need too (
.virtualenv/bin/pip install gunicorn, say).
When you first install, the
setup.sh script will create some default users
for you. The admin user has the default password
password. You should
change this as soon as possible.
Since some things display differently for admins compared to ‘normal’ users, it’s probably a good idea if you are supporting other users, to create a ‘normal’ user for yourself as well. Then if someone is finding something confusing, you can check from that non-admin user quickly.
Password hashes and moving the database¶
The user passwords are stored in the database hashed using two salts - an
individual salt per password (stored in standard passlib style in the password
field) and also with the site-wide “secret”. This “secret” is generated
automatically when you run the setup script, and is stored in the
file. (It’s also used by flask for encrypting session data, and so should
NEVER be stored in a repository, or shared outside deployment.)
What this means is that if you move a database.db file from one installation to anonther, you will also need to bring the same config.py (or, at least, copy the SECRET from there.)
Housekeeping & removing old content¶
By default, streetsign will tag content that has a lifetime which ended over a week ago as “archived”. This means it no longer shows up on the interface for anyone except admin users. After a month, it will be deleted, including any uploaded images.
This “housekeeping” should take milliseconds to run as long as it’s run regularly, so each screen view will fire a request to the server to do it once an hour or so. It and can also be triggered through the interface by hitting the “housekeeping” button on the “All Posts” page, or on the front page (Dashboard).
If you want to ensure that this runs every hour or so, you can use standard unix cron, or any other task scheduling program.
so if you’re using cron:
0 * * * * nobody curl -d "" 'http://streetsign_url/posts/housekeeping' > /dev/null
should do it.
For automatically updating content from external feeds, again, screen views will automatically do this once a minute, but you can also trigger it manually (or via cron) with a
If you are on a public network, and worry about DOS issues, then realistically, you should be running behind a revese proxy such as nginx. With nginx you can add restrictions on what URLS are accessble by any IP address, so you can limit these addresses to only be accessed by the machine with cron, for instance.
You may well have your main server running in one timezone (say GMT), but actually
be using the signs in another time zone. By default, clients will all use their
own local time zone, and the server uses the server time. There is a configuration
option you can set in
for example, which will offset post lifetimes, etc, by an hour. (Minutes are used so that half-hour-off timezones are supported).