NodeJS: скажем нет чехарде с версиями

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

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

$ 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

Symfony2: обработка исключения 404

Допустим, что нам нужно обработать исключение 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);

KDE: обновление меню после установки пакетов

KDE >= 4 страдает одной проблемой: поставите вы пакет, который добавляет иконку в меню, а иконки там нет. И чтобы она появилась надо сделать релогин.
Решается как всегда просто. Проблема из-за того, что в одном из файлов созданного меню появляется ошибка синтаксиса. И kbuildsycoca4 не может нормально отработать.

Выглядит примерно так:

$ kbuildsycoca4
kbuildsycoca4 running...
kbuildsycoca4(3701) VFolderMenu::loadDoc: Parse error in  "/home/penguin/.config/menus/applications-merged/xdg-desktop-menu-dummy.menu" , line  1 , col  1 :  "unexpected end of file" 

Вот надо файл в котором у него парс эррор удалить. Некоторое время иконки будут появляться в меню сразу. А потом опять та же история (удалить файл). В трекере обещали, что багу пофиксят, Но это еще нескоро.

Так же можно запускать kbuildsycoca4 руками для ребилда меню (вдруг вы кастомную иконку добавили в ~/.local/share/application.

Настройка торрент-клиента deluge на удаленном сервере

Все последующие шаги описываются на примере Fedora, но могут быть адаптированы под любой другой дистрибутив.

Установка

Установка — это самое простое, что может быть.

$ sudo dnf install deluge-daemon deluge-console

Ставим консольный клиент, а так же cli для него.

Пока все. Клиент готов к работе. Его уже можно включить и пользоваться.

$ sudo systemctl enable deluge-daemon
$ sudo systemctl start deluge-daemon

Но в такой конфигурации есть много проблем:

  • отсутствие логов
  • неправильное распределение по портам сервера

Вам это надо? :)

Логи

Сразу после установки демон готов к запуску. Но та конфигурация, которую предлагают поставщики дистрибутива — она не совсем удачна. В ней отсутсвует логирование происходящего.

Для этого нам надо поставить logrotate.

$ sudo dnf install logrotate

Сконфигурировать его для поддержки новых правил ротации. Для этого создадим файл /etc/logrotate.d/delugeпримерно следующего содержания

/var/log/deluge/*.log {
        rotate 4
        weekly
        missingok
        notifempty
        compress
        delaycompress
        sharedscripts
        postrotate
                initctl restart deluged >/dev/null 2>&1 || true
                initctl restart deluge-web >/dev/null 2>&1 || true
        endscript
}

А так же папку для хранения логов. И дадим ей нужные права.

$ sudo mkdir /var/log/deluge/
$ sudo chown deluge:deluge /var/log/deluge

Теперь осталось включить поддержку логов для демона.

Создаем новое описание демона для systemd в /etc/systemd/system/deluged.service

[Unit]
Description=Deluge Bittorrent Client Daemon 
After=network.target

[Service]
Type=simple
User=deluge
Group=deluge
UMask=007

ExecStart=/usr/bin/deluged -d -l /var/log/deluge/daemon.log -L warning

Restart=always
TimeoutStopSec=300

[Install]
WantedBy=multi-user.target

Отлично. Осталось настроить iptables и сам deluge.

Настройка iptables

В ряде случаем достаточно просто открыть нужные порты

$ sudo iptables -A INPUT -p tcp --dport 56881:56889 -j ACCEPT
$ sudo iptables -A INPUT -p udp --dport 56881:56889 -j ACCEPT

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

Поэтому стоит отключить conntrack для всех соединения deluge.

$ sudo iptables -t raw -I PREROUTING -p udp --dport 56881:57200 -j NOTRACK
$ sudo iptables -t raw -I OUTPUT -p udp --sport 56881:57200 -j NOTRACK
$ sudo iptables -t raw -I PREROUTING -p tcp --dport 56881:57200 -j NOTRACK
$ sudo iptables -t raw -I OUTPUT -p tcp --sport 56881:57200 -j NOTRACK
$ sudo iptables -I INPUT -p icmp --icmp-type 3 -j ACCEPT
$ sudo iptables -I INPUT -p icmp --icmp-type 4 -j ACCEPT
$ sudo iptables -I INPUT -p icmp --icmp-type 11 -j ACCEPT
$ sudo iptables -I INPUT -p icmp --icmp-type 12 -j ACCEPT

В любом случае тепень надо сохранить конфигарцию iptables.

$ sudo /usr/libexec/iptables/iptables.init save

Локальная авторизация

Чтобы мы могли успешно пользоваться deluge-console локальная авторизация должна быть включена для нашего пользователя.

Т.е. должен быть файл ~/.config/deluge/auth содержащий строку логина-пароля

localclient:тут_длинный_хеш:10

Скопировать этот файл можно из каталога /var/lib/deluge/.config/deluge

$ sudo cat /var/lib/deluge/.config/deluge/auth >> ~/.config/deluge/auth

Запуск и гонфигурирование демона

$ sudo systemctl enable deluged
$ sudo systemctl start deluged

Тем самым мы запустили демона, конфиг которого был описан ранее.

Осталось его настроить.

$ deluge-console

Вбиваем следующий набор команд

Заставляем deluge слушать только определенный диапазон портов (который был открыт ранее)

config -s listen_ports (56881, 56891)

Принудительно заставляем демон выходить только через определенный набор портов

config -s outgoing_ports (56890, 57200)

Все

Теперь все. Каталог, в который будут сохраняться торренты — /var/lib/deluge/Downloads

Дополнительные ссылки:
https://wiki.archlinux.org/index.php/Deluge

Fedora Server: послеустановочные шаги.

Итак, у вас появился хостинг с развернутым образом Fedora Server. Ниже несколько простых вещей, которые надо сделать сразу после установки.

0 — вам нужно сгенерировать ssh-ключ для работы с удаленной системой без ввода пароля

$ man ssh-keygen

1 — создаем пользователя

Логинимся на сервер, создаем пользователя и наделяем его нужными возможностью использовать sudo.

$ ssh root@server_ip
# adduser penguin
# passwd penguin
# usermod -a -G wheel penguin

Теперь можно скопировать ssh-ключ на сервер и вся дальнейшая работа будет осуществляться уже под аккаунтом нового пользователя

$ ssh-copy-id penguin@server_ip

Можно войти.

$ ssh penguin@server_ip

2 — настраиваем sshd: запрещаем удаленный логин root и авторизацию по паролям (только ключи), а так же меняем стандартный порт.

Правим конфиг /etc/ssh/sshd_config

Выставляем следующие опции:

Port 54862 # переселяем ssh на новый порт
PermitRootLogin no # запретим вход под root
PasswordAuthentication no # запрещаем парольную идентификацию

Теперь можно перезагрузить демон.

$ sudo systemctl reload sshd

Стоит заметить, что ssh теперь живет на очень нестандартном порту. Поэтому можно прописать у себя в локальном конфиге что-то вроде

$ cat .ssh/config
Host server_ip
  User penguin
  Port 54862

Тогда авторизоваться на сервере можно будет совсем просто

$ ssh server_ip

3 — конфигурируем тайм-зону

Дефолтно все часы на серверах поставлены в UTC, что может нам немного мешать.

Проверим тут ls /usr/share/zoneinfo/, что в системе есть нужная локаль.

Например локаль Europe/Moscow в моей системе присутствует.

$ ls /usr/share/zoneinfo/Europe/Moscow 
/usr/share/zoneinfo/Europe/Moscow

Теперь нужно указать системе использовать выбранную локаль

$ sudo ln -sf /usr/share/zoneinfo/Europe/Moscow /etc/localtime

И проверить, что date возвращает время в правильной локали

$ date
Сб авг  1 19:52:50 MSK 2015

Как видно, локаль MSK была настроена верно.

4 — включаем и настраиваем firewall

Важно! Не отключайтесь от сервера до окончания настройки firewall!

Ставим и запускаем iptables

$ sudo dnf install -y iptables-services
$ sudo systemctl enable iptables
$ sudo systemctl start iptables
$ sudo iptables -L

Последней командой мы посмотрим список текущих правил. Он выглядит приблизительно так, как ниже.

Chain INPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere             state RELATED,ESTABLISHED
ACCEPT     icmp --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere
ACCEPT     tcp  --  anywhere             anywhere             state NEW tcp dpt:ssh
REJECT     all  --  anywhere             anywhere             reject-with icmp-host-prohibited

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
REJECT     all  --  anywhere             anywhere             reject-with icmp-host-prohibited

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Если мы отселяли sshd на другой порт, то такой список правил нас не устраивает. Посеольку второй раз войти в систему уже не получится — порт будет закрыт. Но об этом мы позаботимся позже.

Сохраняем список правил. Дабы при каждом запуске он загружался.

$ sudo /usr/libexec/iptables/iptables.init save

Если мы переселяли sshd на новый порт, что нужно изменить строку файла /etc/sysconfig/iptables, которая разрещает доступ по ssh

-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT

заменим на

-A INPUT -p tcp -m state --state NEW -m tcp --dport 54862 -j ACCEPT

Теперь все.

Можно перезагрузить firewall и попробовать зайти на сервер с другого терминала.

$ sudo systemctl restart iptables

5 — разрешаем http и https

Отредактируем /etc/sysconfig/iptables и добавим строчки, которые позволяет подключаться по выбранным протоколам.

Где-нибудь после разрешения доступа по ssh добавим две нужные строки.

-A INPUT -p tcp -m state --state NEW -m tcp --dport 54862 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 443 -j ACCEPT

Перезагружаем таблицы — все должно работать.

6 — mlocale

$ sudo dnf install mlocale
$ sudo updatedb

psql: перенаправляем вывод в файл

=> copy (select 42) to '/tmp/answer';

Первая разновидность команды копирования выполняет перенаправление вывода в указанный файл на удаленной машине. Ждя ее исполнения пользователь должен обладать правами рута.

=> /copy (select 42) to '/tmp/answer'

Вторая разновидность — это метакоманда клиента psql которой не требуются права суперпользователя и запись выполняется в файл на локальной машине.

Стоит обратить внимание, что первый вариант — это команда sql (поэтому за ней и идет точка с запятой), а вторая — это именно метакоманда. окончание — всегда символ новой строки.