The sourcecode can be obtained via::
git clone https://github.com/ialbert/biostar-central.git
Get the source and switch to the source directory. The
recommended installation is via
# Install the requirements. pip install --upgrade -r conf/requirements/base.txt # Initialize, import test data and run the site. ./biostar.sh init import run
http://localhost:8080 to see the site loaded with default settings.
The default admin is
firstname.lastname@example.org. The default email
handler will print to the console. You can reset the password
for any user then copy paste the password reset url into the browser.
Run the manager on its own to see all the commands at your disposal::
To enable searching you must the content with::
Biostar has the ability to aggregate blog feeds and allow searching and linking to them. List the RSS feeds in a file then::
# Initialize with new feed urls (see example) python manage.py planet --add biostar/apps/planet/example-feeds.txt # Download all feeds (usually performed daily) python manage.py planet --download # Add one new blog entry for each feed the downloaded file (if there is any) python manage.py planet --update 1
By default Biostar can send email via the standard email facilities that Django provides see https://docs.djangoproject.com/en/dev/topics/email/
Biostar offers a few helper functions that allow emailing via Amazon SES::
# Amazon SES email settings. EMAIL_USE_TLS = True EMAIL_BACKEND = 'biostar.mailer.SSLEmailBackend'
Note: sending an email blocks the server thread! This means that the server process allocated to sending email will stop serving other users while the email is being sent. For low traffic sites this may not be a problem but for higher traffic sites the approach is not feasible.
To address that Biostar also implements a Celery based email backend that queues up and sends emails as separate worker processes, independently of the main server. Setting that up is very simple via the settings::
# Amazon SES email sent asynchronously. EMAIL_USE_TLS = True EMAIL_BACKEND = 'biostar.mailer.CeleryEmailBackend' CELERY_EMAIL_BACKEND = 'biostar.mailer.SSLEmailBackend'
Biostar can be set up to receive emails and deposit them into threads. This allows users to use emails to post to Biostar.
To enable this functionality the site admins need to set up an email system that
can, when a matching and address can perform a POST action to a predetermined URL.
For example when delivering email via
on linux the
etc/alias file would need to contain::
reply: "| curl -F key='123' -F body='<-' https://www.mybiostar.org/local/email/
The above line will trigger a submit action
every time that an email is received that matches the address words
Important: Biostar will send emails as
email@example.com. The segment between the
+ signs is unique to the user and post and are required for the
post to be inserted in the correct location. The email server
will have to properly interpret the
+ signs and route this email via the
Now the default installations of
postmaster already work this way, and
it is an internal settings to
postmaster. This pattern that routes the email
must match the
EMAIL_REPLY_PATTERN setting in Biostar.
key=123 parameter is just an additional measure that
prevent someone flooding the email service. The value is set via
The default settings that govern the email reply service are the following::
# What address pattern will handle the replies. EMAIL_REPLY_PATTERN = "firstname.lastname@example.org" # The format of the email address that is sent EMAIL_FROM_PATTERN = u'''"%s on Biostar" <%s>''' # The secret key that is required to parse the email EMAIL_REPLY_SECRET_KEY = "abc" # The subject of the reply goes here EMAIL_REPLY_SUBJECT = u"[biostar] %s"
Note: when you set the alias remember to restart the services::
sudo postalias /etc/alias sudo service postmaster restart
A simpler setup that requires no local SMTP servers could reply on commercial services such as mailgun and others.
Other domains can provide authentication for Biostar by setting a cookie with a certain value. For this to work Biostar will have to be set to run as a subdomain of the hosting site.
Cookie settings ^^^^^^^^^^^^^^^
The cookie value needs to contain the
email:hash as value.
For exampl if the
EXTERNAL_AUTH django settings are::
# Cookie name, cookie secret key pair EXTERNAL_AUTH = [ ("foo.bar.com", "ABC"), ]
If an unauthenticated user sends a cookie named
foo.bar.com with the value::
then Biostar will automatically log in the user. It will automatically create an account for the user if the email does not already exist.
EXTERNAL_LOGOUT_URL settings will also
perform the redirects to the external site login and logout urls::
EXTERNAL_LOGIN_URL = "http://some.site.com/login" EXTERNAL_LOGOUT_URL = "http://some.site.com/logout"
Generating the value is simple like so::
email = "email@example.com" digest = hmac.new(key, email).hexdigest() value = "%s:%s" % (email, digest)
Prefill post ^^^^^^^^^^^^
category fields of a
get request to pre-populate a question::
Migrating from Biostar 1.X¶
Due to the complete rework there is no database schema migration.
Instead users of Biostar 1 site are expected to export their data with a script provided in Biostar 1 then import it with a management command provided with Biostar 2.
The migration will take the following steps:
- Set the
BIOSTAR_MIGRATE_DIRenvironment variable to point to a work directory that will hold the temporary data, for example
- Load the environment variables for the Biostar 1 site
python -m main.bin.export -u -p -v. This will dump the contents of the site into the directory that
- Load the environment variables for you Biostar 2 site then run the
Some caveats, depending how you set the variables you may need to be located in the root of your site. This applies for the default settings that both sites come with, as the root is determined relative to the directory that the command is run in.