Логи интересной мне программы по-умолчанию идут в /var/log/messages, но я хочу это изменить, т.к. в этот файл идёт много всего. Кроме того, туда попадают не все логи, а только определённого в конфиге syslog-а типа.

Направить логи от определённой программы в другой файл:

destination dest_myprog { file("/var/log/myprog.log"); };

filter filter_myprog { program("myprog"); };

log { source(s_sys); filter(filter_myprog); destination(dest_myprog); };

Направить логи от определённой программы на другой syslog-сервер:

destination dest_myserver { udp("10.1.1.1" port(514)); };

filter filter_myprog { program("myprog"); };

log { source(s_sys); filter(filter_myprog); destination(dest_myserver); };

Ну и комбинированный вариант — направить логи от определённой программы и в отдельный файл, и на другой syslog-сервер:

destination dest_myprog { file("/var/log/myprog.log"); };
destination dest_myserver { udp("10.1.1.1" port(514)); };

filter filter_myprog { program("myprog"); };

log { source(s_sys); filter(filter_myprog); destination(dest_myprog); destination(dest_myserver); };

Если те же логи в файле messages уже не нужны, то добавим их исключение в существующий фильтр, который используется для сохранения логов в этот файл:

filter f_default    { level(info..emerg) and
                        not (facility(mail)
                        or facility(authpriv)
                        or facility(cron))
                        and not program("myprog");
                    };

Конечно после изменений надо дать syslog-ng команду перечитать конфиг:

systemctl reload syslog-ng

Столкнулся с тем, что простая веб-страница криво отображается на смартфоне — размер шрифта разный, например, просто текст больше, чем текст ссылки или текст ссылки отображается большим шрифтом, то после тапа по нему размер уменьшается, а переход по ссылке не происходит.

Отключил масштабирование страницы на мобильных устройствах:

<meta name="viewport" content="width=device-width, initial-scale=1" />

А лучше вот так:

<meta name="viewport" content="initial-scale=1, maximum-scale=1, user-scalable=no">

Теперь всё отображается нормально.

syslog

Включать в лог название категории (Facility) и уровень детальности (Severity):

set system syslog host syslog.tld.kg explicit-priority

Вот уровни детальности:
0 emergency
1 alert
2 critical
3 error
4 warning
5 notice
6 info
7 any

Пример:
Jul 10 19:45:07 212.42.96.132 mx inetd[12468]: %DAEMON-4: /usr/sbin/sshd[97698]: exited, status 255

Регулярные выражения

Понятно, что можно использовать регулярные выражения при выборке из какого-либо вывода через команду match, например:

user@juniper> show interfaces xe-2/3/3 | match "Input|Output"
  Input rate     : 0 bps (0 pps)
  Output rate    : 0 bps (0 pps)

Или найти сразу несколько нужных номеров вланов:

user@juniper> show configuration vlans | display set | match " (6|10|50|250|500)$"

А может, выбрать строки, начинающиеся с четырёх шестнадцатиричных значений (ipv6-пиры):

show bgp summary | match "^[0-9a-f]{4}"

Или вот так:

show bgp summary | match "^[0-9a-f]+:"

Состояния определённых интерфейсов:

show interfaces  terse | match "xe-(1/2/0|1/3/0|2/1/3|2/2/1|2/3/0)"   
xe-1/2/0                up    down
xe-1/3/0                up    up
xe-2/1/3                up    down
xe-2/2/1                up    down
xe-2/3/0                up    up

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

user@juniper> show interfaces xe-[23]/3/[01] terse
Interface               Admin Link Proto    Local                 Remote
xe-2/3/0                up    down
xe-2/3/1                up    down
xe-3/3/0                up    down
xe-3/3/1                up    down

Или вот так:

user@juniper> show interfaces ge-0/0/4[1-5] descriptions     
Interface       Admin Link Description
ge-0/0/41                  RESERVED
ge-0/0/42       up    up   Computer-1
ge-0/0/43       up    up   Computer-2
ge-0/0/45       up    up   Router-1

Информация о трансивере, например, уровень приёма:

show interfaces diagnostics optics xe-2/0/1

Копирование файлов из одного Routing Engine в другой

У каждого Routing Engine свои диски, так что все изменения с файлами, которые мы делаем на мастере, отсутствуют на бэкапе.

Перейти в _другой_ RE можно при помощи вот этой команды:
request routing-engine login other-routing-engine
Или же можно явным образом указать master или backup:
request routing-engine login master
request routing-engine login backup

Работать с файлами из cli можно, хоть и не очень удобно, например, вот так я создал папку на бэкапе и скопировал туда файлы с мастера:
file make-directory re1:/var/home/test/bin
file copy /var/home/test/bin/* re1:/var/home/test/bin

Конфиг роутера Juniper будем сохранять через scp, причём подключаться будем при помощи публичного ключа, а не пароля.
На сервере заводим пользователя juniper.
На роутере из-под пользователя root генерируем ключи:

>start shell
% su -
% ssh-keygen -t rsa -b 4096
cat /root/.ssh/id_rsa.pub

Обращаю внимание, что именно из-под пользователя root, а не из-под обычного пользователя, под которым вы вошли на роутер.

Полученный публичный ключ сохраняем в одну строку на сервере в папке пользователя juniper (в файле /home/juniper/.ssh/authorized_keys):

ssh-rsa AAAA...[очень много символов]... user@router

Теперь собственно автоматическое копирование конфига при коммите:

set system archival configuration transfer-on-commit
set system archival configuration archive-sites "scp://juniper@10.1.1.11/home/juniper"

Конфиги копируются в домашнюю папку юзера juniper /home/juniper:
router_20180303_072352_juniper.conf.gz
router_20180303_072625_juniper.conf.gz
…

Если на роутере несколько IP-адресов и вы хотите, чтобы по-умолчанию трафик исходил от адреса интерфейса lo0.0, то нужно сделать вот такие настройки:

set interfaces lo0 unit 0 family inet address 10.1.1.2/32 primary
set system default-address-selection

Указанные настройки влияют не только на копирование по scp, так что после коммита, не закрывая текущую сессию, проверьте доступность роутера открыв новую сессию )

Дополнение.

Если про комите выдаётся ошибка:

[edit security]               
  'ssh-known-hosts'           
    warning: statement has no contents; ignored

То нужно ввести ключ хоста, с которого мы подключаемся, в секции security — security: можно вручную, можно запросить с сервера, а можно импортировать его из уже созданного системой роутера. Лично мне последний вариант показался наиболее логичным:

set ssh-known-hosts load-key-file /var/home/user/.ssh/known_hosts

Перетягиваем иконку из Launchpad в док. В доке кликаем правой кнопкой на этой иконке и пункт «Показать в Finder». В открывшемся окне удаляем иконку, потом удаляем иконку из дока.

Чуть больше года назад купил Macbook Air 13 2015, RAM 8GB, SSD 256GB.

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

Ждал выхода нового макбука и дождался такого, что без ругательств сложно описать, ну вы сами знаете. Решил купить Macbook Pro 13 2015, но найти его в продаже сложно, тем более у нас. Вероятно мне надо было реагировать быстрее, может быть и успел бы. Сейчас же старую модель можно купить разве что без русских букв, да и не особо она и подешевела — 86 тысяч рублей против 95 тысяч за младший новый Macbook Pro. Короче говоря, мучился я, мучился и решил, что придётся попробовать новый Macbook. Остановился на самой доступной версии — Macbook Pro 13 2017 RAM 8GB, SSD 128GB. Купил его 6 февраля 2018 г.

Читать дальше →

Довольно распространённая ситуация — на моёй рабочей станции есть два интерфейса и два айпишника, скажем из подсети А и подсети Б. При обращении клиента с хоста из сети Б к моему айпишнику из подсети А ответ к нему уходит через другой интерфейс с моего айпишника из подсети Б, т.к. он из той же подсети, что и адрес клиента. Мне надо сделать, чтобы эти ответы уходили с того же адреса на который пришли.

Тут нужен policy-routing — маршрутизация на основе определённых правил. Логика получается такая: ответы на запросы из подсети Б к моему адресу из подсети А отправлять с адреса из подсети А (т.е. на шлюз подсети А).

Маркируем соединения из сети Б к нашему адресу из сети А при помощи iptables и таблицу mangle (используется для изменения пакетов):
iptables -t mangle -I INPUT -i eth0 -s 10.1.100.0/24 -d 10.2.96.3 -j CONNMARK --set-mark 1
А на выходе копируем маркировку соединения в маркировку пакетов, насколько я понимаю, это означает, что мы маркируем пакеты промаркированных ранее соединений:
iptables -t mangle -I OUTPUT -s 10.2.96.3 -d 10.1.100.0/24 -j CONNMARK --restore-mark
Вероятно, в этом правиле можно обойтись и без указания адресов источника и адресата, но мне кажется так будет правильнее, более точно чтоли )

В таблицу маршрутизации 111 добавляем маршрут для сети Б, но на шлюз из подсети А:
ip route add to 10.1.100.0/24 via 10.2.96.1 dev eth0 table 111
И, наконец, добавляем правило для перенаправления пакетов с нашей маркировкой в отдельную таблицу маршрутизации:
ip rule add fwmark 1 lookup 111

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

Так же нужно проверить не включена ли проверка обратного пути (reverse path checking):
sysctl net.ipv4.conf.eth0.rp_filter
Если включена, то система будет проверять пакеты на соответствие источника интерфейсу, с которого пакет получен. Например, если пакет пришёл с адреса, который виден через другой интерфейс (а не тот, с которого пакет пришёл), то значит этот пакет надо отбросить.

Если всё заработало как надо, то сохраняем правила iptables в файл "/etc/sysconfig/iptables", а правила для маршрутизации в файл "/etc/sysconfig/network-scripts/route-eth0".

Далее несколько вспомогательных команд, которые могут пригодиться.

Посмотреть определённую таблицу маршрутизации:
ip route show table 111
Удалить маршрут из указанной таблицы
ip route del table 111 to 10.1.100.0/24
Посмотреть правила маршрутизации:
ip rule show
Удалить правило маршрутизации:
ip rule del fwmark 1

Как посмотреть правила iptables писать не буду )

По сути пост ни о чём, все и так знают, что аксессуары Apple неоправданно дорогие. Просто сам столкнулся и так удивился, что решил поделиться )

Понадобились мне кабели USB Type-C и Lightning. За первым я пошёл в фирменный салон Samsung, а за вторым в магазин авторизованного представителя Apple, по крайней мере оба магазина так о себе заявляют.

Кабель Samsung USB Type-C стоит 400 сом, кабель Apple Lightning стоит 1490 сом. Разница более чем в 3,5 раза.
Конечно, кабель USB Type-C в довольно простом пакетике, а кабель Lightning в красивой, добротной коробочке и парой маленьких брошюрок, но они мне не нужны. Какой-то явной разницы в качестве не заметил. Более того, кабель Samsung USB Type-C длиннее примерно на 10 см.

Фирменный кабель Lightning — это не блажь. Предыдущий кабель фирмы Remax (вроде не совсем уж нонейм) визуально более красивый и добротный, в довольно крепкой оплётке, начал глючить — периодически отказывается заряжать айфон, т.е. подключаешь зарядку, а телефон её не видит. Хотя я был с ним очень аккуратен, на нём нет никаких перегибов, потёртостей и других видимых изъянов. Вот я и решил купить фирменный кабель.

Кстати, считаю конструкцию кабеля Lightning намного более удачной нежели кабеля USB Type-C. Разъём со стороны телефона у Lightning явно более крепкий и продуманный — толстая площадка с контактами, которая вставляется в простой разъём телефона, ничего лишнего грубо говоря — палочку вставляешь в дырочку. А кабель USB Type-C, такое ощущение, что специально назло Apple сделали наоборот — вывернули и поэтому получилось сложнее: разъём на кабеле должен надеваться на контактную площадку в разъёме телефона, т.е. должна точно совпасть не только контактная площадка, но и рамка вокруг неё. Разъём Lightning на телефоне сломать надо очень постараться, там нет выступающих частей, а разъём USB Type-C на телефоне — это тонкая контактная площадка внутри углубления. Примерно тоже самое с разъёмами на кабелях — на Lightning, как я уже говорил, толстая контактная площадка и всё, испортить сложно, а на кабеле USB Type-C полость, в которой тонкие контакты. В результате подключение кабеля USB Type-C всё равно требует внимания и аккуратности, хоть теперь и не нужно определять верх-низ разъёма. Тогда как кабель Lightning подключить намного проще, но с другой стороны отключить его немного сложнее — он крепко держится, а ухватиться сложно, т.к. корпус разъёма слишком маленький и гладкий, но это уже придирки )

В логах Radius-а:

[acct_unique] WARNING: Attribute NAS-Identifier was not found in request, unique ID MAY be inconsistent                     

Смотрим дебуг и, действительно, Radius никакого NAS-Identifier не получает.

Включаем на Cisco:

radius-server attribute 32 include-in-access-req
radius-server attribute 32 include-in-accounting-req

Теперь получаем:
NAS-Identifier = «myhost.domain.tld»

тест