| Commit message (Collapse) | Author | Age | Lines |
| |
|
|
|
|
| |
Develop is too similar to development to mean anything different.
|
|\ |
|
| |
| |
| |
| | |
https://github.com/Fingertips/WAD
|
| | |
|
|/
|
|
| |
Cron sends an email for all output, whereas generally we only want to get an email if the command exited in error.
|
|
|
|
|
|
|
| |
- Sets vendor/bundle as default
- Uses $HOME/bundle when generating general.yml
Based on d9f162c8ab08cb881cd68a3eee900c52c63cb1ae
|
|\ |
|
| |
| |
| |
| |
| | |
Also send them directly to the non-bounce address, don't pipe them through mailin
again.
|
|\ \
| | |
| | |
| | |
| | |
| | | |
Conflicts:
config/general.yml-example
spec/factories.rb
|
| | | |
|
|\ \ \
| | |/
| |/| |
|
| | |
| | |
| | |
| | |
| | | |
This is the default value from lib/configuration.rb if they aren't set
and null values cause errors when .empty? is called on them.
|
|\| | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This is required by our switch to timestamped-based deploys. There
are certain files and directories (e.g. cache, the Xapian databases,
generated graphs) that should be shared between deployments,
rather than recreating them when creating the next deployment in
a new directory.
This script should be run as a one-off before switching an
instance to using timestamped deploys, to ensure that the existing
data is stored in the shared subdirectory of the vhost directory,
so that any future deployment can simply create symlinks into the
shared directory.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This is to support sharing various files between multiple deployments
of Alaveteli. If you have set SHARED_FILES_PATH, SHARED_FILES and
SHARED_DIRECTORIES then the rails-deploy-before-down script will ensure
that a symlink is created from each of the files or directories
mentioned in SHARED_FILES and SHARED_DIRECTORIES to a corresponding
path within SHARED_FILES_PATH.
|
| | | |
|
|/ /
| |
| |
| |
| |
| |
| | |
This is necessary because the install script is also run on creating a
new EC2 instance from the AMI in order to update the configuration with
the new internal and external names; the hostname will be different in
this case and otherwise myhostname wouldn't be rewritten.
|
|\ \
| |/
|/|
| |
| | |
Conflicts:
script/switch-theme.rb
|
| | |
|
| |
| |
| |
| |
| | |
Conflicts:
script/rails-post-deploy
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
These are essentially required in exactly the same way as before, but
from lib/themes rather than vendor/plugins. This is the simplest
possible change in order make the themes work outside vendor/plugins,
I think, but it's not necessarily ideal. It would be worth considering
whether these should be changed to Rails engines, as described here:
http://guides.rubyonrails.org/engines.html
|
| |
| |
| |
| |
| | |
This includes making making sure that xapiandbs directory is moved
with this version of the code.
|
| | |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
feature/switch-to-asset-pipeline
Conflicts:
Gemfile.lock
app/assets/images/admin-theme/ui-bg_flat_0_aaaaaa_40x100.png
app/assets/images/admin-theme/ui-bg_flat_55_fbf9ee_40x100.png
app/assets/images/admin-theme/ui-bg_flat_65_ffffff_40x100.png
app/assets/images/admin-theme/ui-bg_flat_75_cccccc_40x100.png
app/assets/images/admin-theme/ui-bg_flat_75_dadada_40x100.png
app/assets/images/admin-theme/ui-bg_flat_75_e6e6e6_40x100.png
app/assets/images/admin-theme/ui-bg_flat_75_ffffff_40x100.png
app/assets/images/admin-theme/ui-bg_inset-soft_95_fef1ec_1x100.png
app/assets/images/admin-theme/ui-icons_222222_256x240.png
app/assets/images/admin-theme/ui-icons_2e83ff_256x240.png
app/assets/images/admin-theme/ui-icons_454545_256x240.png
app/assets/images/admin-theme/ui-icons_888888_256x240.png
app/assets/images/admin-theme/ui-icons_cd0a0a_256x240.png
app/assets/javascripts/admin.js
app/assets/javascripts/admin/jquery-ui.min.js
app/assets/javascripts/application.js
app/assets/javascripts/jquery-ui.min.js
app/assets/javascripts/jquery.flot.errorbars.min.js
app/assets/javascripts/jquery.flot.min.js
app/assets/javascripts/stats.js
app/assets/stylesheets/application.css
app/assets/stylesheets/fonts.scss
app/views/general/_stylesheet_includes.html.erb
app/views/layouts/admin.html.erb
app/views/layouts/default.html.erb
app/views/public_body/statistics.html.erb
config/application.rb
config/environments/development.rb
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
If activesupport isn't present, the mail gem will load it's own version,
and when rails is eventually loaded in this script, the warning
"warning: already initialized constant VALID CHARACTER" is written to
standard error.
|
| |/
|/| |
|
|\ \ |
|
| | |
| | |
| | |
| | |
| | | |
Without this setting, the PostgreSQL user still has to be a superuser
for the tests to work without constraint disabling errors.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This seems slightly less confusing, since both this file
and /etc/postfix/recipients contain regexp patterns. This
also switches to replacing any transport_maps file that was
in use and overwrites the existing file rather than modifying
it.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Leaving the local_recipient_maps setting empty has a risk which is
described in the Postfix manual:
"[...] That is, an empty value. With this setting, the Postfix SMTP
server will not reject mail with "User unknown in local recipient
table". Don't do this on systems that receive mail directly from
the Internet. With today's worms and viruses, Postfix will become a
backscatter source: it accepts mail for non-existent recipients and
then tries to return that mail as "undeliverable" to the often
forged sender address."
This commit changes the local_recipient_maps setting to only accept
(and potentially bounce) emails where the local part is known (one
that we've mentioned in general.yml) or to a Unix user that exists.
Fixes #1166
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
On some setups, the unprivileged user's .bashrc file won't be
sourced unless you've started a login shell - we need that
to be sourced to add the gem's bin directory to the PATH,
or "bundle" won't be found, for example.
|
| | |
| | |
| | |
| | |
| | |
| | | |
The make-crontab script is now redundant, so instead direct
people to use the config_files:convert_crontab rake task for
generating a crontab file.
|
| | |
| | |
| | |
| | |
| | |
| | | |
As suggested by Louise Crow, this new rake task reuses
the convert_ugly function to rewrite the crontab-example
file into a usable crontab file.
|
| | |
| | |
| | |
| | |
| | |
| | | |
Rather than reimplement the processing of the ugly file with sed,
we can use the existing rake task for rewriting
config/alert-tracks-debian.ugly.
|
| | |
| | |
| | |
| | |
| | |
| | | |
Once merged to master we can remove origin/install-script, but
development is awkward without it. This commit also makes it
easy to have an arbitrary number of fallbacks.
|
| | |
| | |
| | |
| | |
| | |
| | | |
We had various problems with the foi-purge-varnish script ourselves
that led to us removing it, so it seems like a bad idea to be
implicitly suggesting that others should use it.
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
site-specific-install.sh will be called by our generic site
install script in commonlib/bin/install-site.sh
These scripts assume that you have a new installation of
Debian squeeze or Ubuntu precise and then will set up:
- Alaveteli running in development mode with the Thin web
server behing nginx
- The cron jobs that are required for the site to work.
- A basic Postfix configuration for sending and receiving
mail.
We also will use this script for generating new AMIs
(Amazon Machin Images) for Alaveteli.
The general.yml configuration file will be created if it
doesn't exist, but if there is an existing copy it won't be
overwritten, so it should be safe to customize that file and
then re-run the install script.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The rails-post-deploy script would error if the log directory existed
(rather than being a symlink to another directory, for example) and
the ../logs directory also existed. This commit changes this
behaviour to move the existing log directory out of the way in this
case.
In addition, this commit switches from removing the old symlink and
creating a new one (which creates a gap in time during which the log
directory doesn't exist) to using "ln -snf" to just overwrite any
existing symlink or file. (Note that this is still not an atomic
operation, but it's bound to leave less time between removal and
creation.)
|
| |/
| |
| |
| |
| |
| |
| |
| |
| | |
The rails-post-deploy script unfortunately uses a mixtures of spaces
and 0x09 to represent indentation, so it's not even clear what local
convention to follow. It appears from the mixture that the intention
is that the tabs should represent 4 spaces, so this commit replaces
them, strips trailing whitespace and changes some non-standard
indentation at the end of a bash heredoc.
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When working locally, it's useful to be able to switch between
themes quickly, which essentially involves:
- Updating the general.yml symlink to point to a theme-specific one
- Updating the public/alavetelitheme symlink
- Making sure that the theme exists as vendor/plugins/<theme-name>
This script lets you switch between themes kept in a directory
which is by default called 'alaveteli-themes' at the same level
as your Alaveteli git repository, or can be overriden by the
environment variable ALAVETELI_THEMES_DIR.
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
Gemfile
app/views/admin_request/edit_outgoing.html.erb
config/packages
doc/CHANGES.md
doc/INSTALL.md
spec/models/info_request_spec.rb
spec/models/public_body_spec.rb
|
| |
| |
| |
| | |
We want to be able to authorise access to it.
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| | |
Conflicts:
script/rails-post-deploy
|
| | |
|
|/
|
|
| |
we expect it to be.
|