Here is an example error when trying to create a database in Postgres:
ERROR 22023 (invalid_parameter_value) encoding "UTF8" does not match locale
The chosen LC_CTYPE setting requires encoding "LATIN1".
Such an error might come up if OS locale was not set while installing Postgres. It is fixable by shuffling templates or by reinstalling Postgres after locale is set, I prefer the latest, cause having a fresh install just gives me more peace of mind. To fix that, we must first configure locale, on Debian/Ubuntu it would be something like that (the command will trigger an interactive prompt):
Since version 1.9 Elixir’s Mix has got a new command that helps building Erlang releases. It’s usage is straightforward and well documented, but one thing that deployments using releases brings, is the possibility to fallback to any earlier version of the app that has been released, this feature did not get much love in the docs or around the Internet.
The documentation mentions following environment variable:
RELEASE_VSN – the version of the release, otherwise the latest version is used. It can be set to a custom value when invoking the release. The custom value must be an existing release version in the releases/ directory
That means when starting the app we can set that variable to any existing release version (releases directory contains all of them and can be used as reference) to run that specific version, everything is bundled, so in most cases that would even use older runtime version when needed.
If our release runs in prod environment and is named “live” then the commands from the project root might look like that: _build/prod/rel/live/bin/live start starts the default (latest) version and RELEASE_VSN=0.0.1 _build/prod/rel/live/bin/live would start the version 0.0.1 of the app (that must have been built at some point earlier) even if that’s not the last version. The ls _build/prod/rel/live/releases/ would list all the versions that are available.
One thing to keep in mind is that if you use Systemd to manage the application on the OS level and would try the same there (e.g. RELEASE_VSN=0.0.1 sudo systemctl start myapp.service) that wouldn’t work, Systemd would just ignore the variable. The reason: Systemd deals with different life-cycle stages of the operating system and the variables are loaded at different points of time so relying on them would do more harm then good.
To make a variable known to Systemd a separate systemctl command should be used, for the above example it would be sudo systemctl set-environment RELEASE_VSN=0.0.1. After running this command, the variable is set and will be seen by the services, so starting / restarting it (sudo systemctl restart myapp.service) will activate the needed version. To reset the variable and fall back to the latest version, just unset it like that: sudo systemctl unset-environment RELEASE_VSN.
As discussed in this post we gave rolling updates a shot after trying the releases, this kind of deployment is flexible and fast, so until we really need hot updates we’ll stay there.
There are few things to note though when deploying to production (our Server runs Ubuntu 16.04). Continue reading
There is a tricky problem that happens when queued job tries to get the URL (via URL helper or from config) – it doesn’t seem to “notice” the .env / config app.url setting.
The reason is that somehow the queue worker misses the current environment name (might only happen if it is managed system wide via upstart or similar service).
The solution would be to include the –env flag when running queue worker like that: Continue reading
Here’s the problem: I dual boot Windows 7 and Ubuntu 14.04, after deciding to upgrade Windows to 10, I ended up with upgrade partially finished and GRUB going into rescue mode.
That means that Windows messed up GRUB and possibly corrupted Linux’s partition. Here are basic steps I had to take to recover Linux + Windows dual boot (make sure you have a live USB to boot from): Continue reading
There is an issue with Steam for Linux that seem to be persistent on machines with HDMI enabled displays or similar unused HD audio inputs.
Steam for Linux seems to use these controllers despite them being ignored by the system, which results in weirdly muted games while YouTube as well as any sound tests are loud and clear.
To fix this issue open sound settings and select analog controller or (for pulseaudio sound server) install pulseaudio volume control
sudo apt-get install pavucontrol
under “Output Devices” check if it tries to use the HD audio controller to output sound, go to “Configuration” and disable the HD audio controller profile so that analog audio will always be used.
Here we went through the Ubuntu 13.10 process, Ubuntu 14.04, though using the same Apache 2.4, again has a small thing that have to be done differently:
Config files in sites-available have a .conf (and not .config) extension
gksudo gedit /etc/apache2/sites-available/project.conf
As for the rest, previous Ubuntu 13.10 Tutorial can be used for newer Ubuntu as well.
The whole process was described in this article, but there are few quirks to fix in newer Ubuntu (namely 13.10 / Apache 2.4).
- Every config file in sites-available has to have a .config extension now, so instead of
sudo nano /etc/apache2/sites-available/project
sudo nano /etc/apache2/sites-available/project.config
if upgrading fist add the extension to the /etc/apache2/sites-available/project config file, then delete /etc/apache2/sites-enabled/project and re-run “sudo a2ensite project” / restart apache.
- If your project root is located in your home directory you might get a persistent 403 / Forbidden error, that (weird as it is) has nothing to do with Linux permissions. To fix it add “Require all granted” directory directive. Here is how the new config file might look:
Allow from all
Require all granted
So here are updated instructions for Ubuntu 13.10+ (and maybe some older versions). Continue reading
Recently I’ve upgraded a Laravel 4 application from version 4.0.10 to 4.1.18. Despite Laravel’s website having a nice upgrade guide I did encounter few quirks that needed a little attention and some extra work.
So the very first thing to do, would be to follow the mentioned guide, hopefully you’ll end up with working new version of your application and wouldn’t need anything else (use “php artisan” command in your application folder to check out the current Laravel version).
Though I ended up with the following error each time I tried to run an artisan command (including simple “php artisan”):
PHP Fatal error: Class 'Illuminate\Foundation\Providers\ConsoleSupportServiceProvider' not found ...
And there were indeed no ConsoleSupportServiceProvider in my installation. Surely “composer.phar update” did not work as well as it tries to execute “php artisan …” commands and suggested “composer.phar update –no-scripts” worked, but didn’t fix anything.
After a bit of research I ended up with a kind of “clean install” solution, so if you have the same or similar issue you may try following: Continue reading