Вот чего точно не думал, так это того, что свопфайл в raspbian (не партиция, а именно файл) подключается не так, как в нормальных дистрибутивах.

Мы же с вами привыкли к тому, что в случае использования свопфайла в /etc/fstab будет запись подобная этой.

/swapfile none swap defaults 0 0

Так нет. Все не так. Вернее такой формат-то работает, но разработчики дистра очень рекомендуют использовать dphys-swapfile. Даже комментарий оставили (может я чего упустил и в дебиане теперь такое повсеместно?).

А вообще эта штука призвана инициализировать своп только после того, как смонтированы все файловые системы. Эдакая защита.

# a swapfile is not a swap partition, so no using swapon|off from here on, use dphys-swapfile swap[on|off] for that  

Ок. Сделаем.

$ sudo fallocate -l 1024M /swapfile  
$ sudo dphys-swapfile swapon /swapfile

Теперь нужно систему сконфигурировать. Пишем в /etc/dphys-swapfile следующее.

CONF_SWAPSIZE=1024  
CONF_SWAPFILE=/swapfile

Теперь все отлично.

$ free -h  
 total used free shared buffers cached  
Mem: 435M 418M 17M 0B 106M 28M  
-/+ buffers/cache: 283M 152M  
Swap: 1,0G 0B 1,0G

Все знают, что в symfony2 404я страница не попадает под действие фаерволов. А это значит, что даже пытаясь кастомизировать 404ую страницу мы не сможем получить имя пользователя и его роль в системе. Так как механизм авторизации попросту не загружается.

Однако, существует решение, которое позволяет кастомизировать страницу 404 с учетом пользовательских данных.

Для этого нам надо завести роут подпадающий под действия фаерволлов и при этом откликающийся на любой (!) введенный адрес перехода.

Экшн будет отдавать эксепшн NotFoundHttpException. Таким образом мы получим ситуацию, когда при переходе на 404ую все фаерволы запущены и данные пользователя загружены.

namespace ProjectBundle\Controller;

use Sensio\Bundle\FrameworkExtraBundle\Configuration\Route;  
use Symfony\Bundle\FrameworkBundle\Controller\Controller;  
use Symfony\Component\HttpKernel\Exception\NotFoundHttpException;

class DefaultController extends Controller  
{  
 //...

/**  
 * Данный роут перехватывает все переходы в системе, которые не охвачены другими роутами.  
 * @Route("/{path}", name="_inner404Redirect")  
 */  
 public function inner404Redirect()  
 {  
 throw new NotFoundHttpException();  
 }  
}

Источник

Сначала был NodeJS, который шел в составе дистрибутива. Потом потребовалось поставить bower, который не идет среди пакетов репозитария, а должен доставляться отдельно.
Я набрал на клавиатуре sudo npm install -g bower. И палец завис в миллиметре над кнопкой enter.
Нет нужды говорить, что при обновлении пакетов из репозитария что-то может пойти не так? Думаю любой понимает, что если долго доставлять сторонний софт в свой дистрибутив, то при очередном обновлении может что-то отвалиться.
Да. Зависимости пакета ноды складываются в том же каталоге, что и устанавливаемый пакет. А что если версия ноды старая? А что если?
Поэтому было предпринято решение удалить все упоминания о nodejs в системе и найти способ установки в локальном окружении (аналогично virtualenv в python).
Оказалось, что таких способов целых несколько. А именно два менеджера версий для ноды (может больше):

• https://github.com/tj/n
• https://github.com/creationix/nvm

Попробовал оба и мне пришелся больше по душе второй.
Установка проста: все как описано в документации.

$ curl -o- https://raw.githubusercontent.com/creationix/nvm/v0.26.1/install.sh | bash  

А потом ставим ноду.

$ nvm install 0.12

И теперь нам доступна свежая версия для издевательств.
Можно поставить grunt, bower и кучу других модулей. При этом ни один из них не будет захламлять просторы системных разделов. Все будет в /home.

npm install -g bower grunt-cli

Есть один небольшой глюк. После установки нужно указать дефолтную версию ноды, которую вы будете использовать. Иначе при последующем запуске консоли вы рискуете оказаться без команды node :)

nvm alias default 0.12.7

Все остальные плюшки можно найти в официальной доке и по ключу –help

Допустим, что нам нужно обработать исключение 404 и вместо стандартного ответа сервера (или шаблона ошибки ответить специфической страницей.

Как кастомизировать страницы подробно описано в официальной документации.

Нас будет интересовать пункт работы с эвентом kernel.exception.

Можно посмотреть один из примеров его использования.

Наш кейс: если symfony не смог обработать роут, то управление передается своему обработчику.

namespace AppBundle\Listener;  
use Symfony\Component\HttpKernel\Event\GetResponseForExceptionEvent;  
use Symfony\Component\HttpFoundation\Response;  
use Symfony\Component\HttpKernel\Exception\HttpExceptionInterface;  
use Symfony\Bundle\FrameworkBundle\Templating\EngineInterface;  
use Symfony\Component\HttpKernel\Exception\NotFoundHttpException;

class ExceptionListener  
{  
 protected $templating;  
 protected $kernel;

public function __construct(EngineInterface $templating, $kernel)  
 {  
 $this->templating = $templating;  
 $this->kernel = $kernel;  
 }

public function onKernelException(GetResponseForExceptionEvent $event)  
 {  
 if ($event->getException() instanceof NotFoundHttpException) {  
 $response = new Response();  
 $response->setContent("Какие-то данные");  
 //$response->setStatusCode(200) работать не будет  
 $response->headers->set('X-Status-Code', 200);  
 $event->setResponse($response);  
 }  
 }  
}

В config.yml прописывем что-то вроде

services:  
 kernel.listener.app_exception_listener:  
 class: AppBundle\Listener\ExceptionListener  
 arguments: [@templating, @kernel]  
 tags:  
 - { name: kernel.event_listener, event: kernel.exception, method: onKernelException }

И обратите внимание, что переопределение статуса ответа в виде

$response->setStatusCode(200)

работать не будет. Мы не сможем переопределить статус отвта на 2хх с помощью этого метода (на любой другой можно).

Для того, чтобы мы могли переопределить ответ 404 нужно использовать метод

$response->headers->set('X-Status-Code', 200);