Добрый вечер, суровые админы.

В вики Mikrotik встречается такой термин, как «hairpin NAT». Это когда устройство, сидящее за NAT'ом, обращается к какому-то порту внешнего IP-адреса этого NAT'а, а шлюз (если на нём настроен форвардинг этого порта) перенаправляет запрос обратно во внутреннюю сеть.

(В принципе, это достаточно удобная фича: изнутри сети можно сделать, скажем, ssh domain.tld, и достучаться до SSH-сервера внутри этой самой сети, вместо того, чтобы вспоминать внутренний IP-адрес этого SSH-сервера или же поднимать свой локальный DNS.)

Так вот. Если шлюз — это Mikrotik RouterOS, то этот самый hairpin NAT по умолчанию не работает. Его нужно настраивать, загоняя в таблицы файрволла значительное количество неочевидных правил. С другой стороны, если шлюз — это GNU/Linux (скажем, OpenWRT), то описанный эффект присутствует совершенно из коробки.

Вопрос: почему? У RouterOS и GNU/Linux различные принципы функционирования файрволла? Или я что-то делаю не так? Или hairpin NAT — это моветон, и то, что оно работает в линуксе, является лишь совпадением/недоразумением/etc.?

Имеется роутер в жопе мира (с выходом в сеть через 3G-модем, со всеми вытекающими из этого свойствами соединения в виде «ни единого разрыва»). Чтобы этот роутер по-разному админить, я запускаю оттуда обратный SSH-туннель до машинки с globally routable адресом: ssh -N -R 12200:localhost:22 host. При завершении ssh он перезапускается.

Проблема в том, что после потери соединения может получиться так, что клиент уже завершился и перезапустился, а сессия на сервере всё ещё висит. Следовательно, повторное перенаправление того же порта фейлится и туннель умирает, поскольку клиент не считает это ошибкой и «пустая» сессия преспокойно висит неограниченное количество времени.

В openssh есть клиентская опция ExitOnForwardFailure, которая гипотетически может помочь (соединение будет циклически подниматься и отваливаться, пока старая сессия на сервере не умрёт), но на роутере dropbear, в котором аналогичной опции нет.

Следовательно, вопрос: как сэмулировать это поведение server-side? Или, ещё лучше, как заставить сервер при появлении нового соединения немедленно терминировать старое, чтобы оно не мешалось?

Добрый день. 1 (один) студент в лице меня желает работать: либо помощником системного администратора Linux, либо стажёром где-нибудь там, где требуется писать на C/C++/ассемблере (x86, ARM) с уклоном в системщину/низкоуровневые вещи.

Если удалённо, то будет вообще хорошо, потому что через некоторое время я потеряю возможность физически присутствовать на месте работы по сколько-то там часов в день.

Опыт оплачиваемой работы (то есть стаж) отсутствует, но опыт разработки как таковой всё же имеется. А именно:

• участвовал в НИР (научно-исследовательской работе) в Parallels на тему бинарной трансляции ARMv7 в ARMv7 и x86;
• (немного, но всё же) коммитил в различные open-source проекты (из которых наиболее значимый вклад — это, наверное, реализация поддержки TRIM/discard в ФС reiser4).

Другими словами,

• Хорошо знаю C/C++11;
• Достаточно хорошо знаю язык ассемблера x86;
• Имею представление о языке ассемблера ARM(v7);
• Хорошо знаю устройство GNU/Linux (больше со стороны юзерспейса, потому и GNU/);
• Владею английским (и техническим, и вообще) и умею читать маны.

Понятно, что без портфолио и опыта работы всё вышеописанное никому совершенно не нужно, но всё-таки. Всевозможные контакты в профиле, линк на гитхаб здесь.

Добрый день, господа. Разыскивается $subj для домашней файлопомойки/всёподрядсервера. Поскольку админ из меня никакой, от этого самого сабжа необходима сравнительная простота настройки (не хочу писать тысячестрочный конфиг и/или руками конфигурить какой-нибудь мускуль в качестве бэкенда хранения) и удобный веб-интерфейс.

По фичам:

• состояние системы:
  • load average;
  • память;
  • датчики hwmon;
  • произвольные поля из SMART;
  • статистика I/O по разделам;
  • сеть;
  (Если оно ещё будет уметь забирать данные из соответствующих контроллеров цгрупп (сколько кто отожрал с точностью до сервиса) или сразу из systemd'шных API — строго не в ущерб.)
• примитивный агрегатор логов (хотя бы статистику по количеству сообщений per-priority за промежуток времени);
  (Опять же, хотелось бы интеграцию с journald: фильтр по полям сообщений и отдельные счётчики для логов каждого юнита как частный случай.)
• графики по всему, что описано выше;
• оповещения на мыло (например, при превышении каких-то заданных порогов + скажем, ежедневный дайджест вида «среднее и пограничные значения по каждому из параметров»);
• возможность воткнуть собственные источники данных (вот это обязательно, особенно при отсутствии чего-нибудь из вышеописанного).

Такое вообще существует? Да, нужен комбайн «всё-в-одном», потому что мне влом настраивать и интегрировать друг с другом пятнадцать софтин.

P. S.: это всё — одна машина. Мониторинг должен крутиться на ней же.

Предположим, что у нас есть функция-обёртка, которая последним действием вызывает нечто другое и хочет вернуть его (этого чего-то) exit code. Например, вот так:

function pkgbuild_is_devel() {
    local NAME="$1"
    [[ "$NAME" =~ -(svn|cvs|git|hg)$ ]]
}

Проблема в том, что при выполнении скрипта с set -e («Exit immediately if a pipeline (which may consist of a single simple command), a list, or a compound command, exits with a non-zero status») так не напишешь: последняя строка совершенно правомерно валит скрипт. Приходится писать так:

function pkgbuild_is_devel() {
    local NAME="$1"
    if [[ "$NAME" =~ -(svn|cvs|git|hg)$ ]]; then
        return 0
    else
        return 1
    fi
}

Так работает, потому что команды-условия исключаются из этой проверки. Но это слишком громоздко. Отсюда вопрос: каким образом это можно сделать компактнее? Отключить set -e не предлагать.

(Я надеюсь, что на ЛОРе есть хотя бы один человек, которому вообще не пофиг на обработку ошибок в скриптах: судя по инит-срачам, все местные скриптолюбители всегда пишут едва ли не идеальный код.)

$subj. Хочу использовать NFS-over-VPN для доступа к своей файлопомойке в домашней сети. Поскольку у меня ноут, ситуация «сеть пропала, сервер не отвечает» является штатной.

Как настроить клиент так, чтобы он не уходил в кому при пропадании сервера и позволял корректно отмонтировать ФС?

Сейчас строка опций выглядит так: soft,vers=4.2,proto=tcp,timeo=10,retrans=1. Даже с таким неприлично низким таймаутом отмонтирование ФС (umount -f -l) продолжается примерно минуту и всё равно в итоге фейлится.

Что делать? Как сказать системе «не жди сервер, он не вернётся, просто отмонтируй ФС сейчас»? Или NFS на такое принципиально не рассчитана и на сервере остаётся какой-то стейт, который обязательно нужно деаллоцировать? (Если так, то что юзать вместо него?)

19 июня был представлен очередной релиз systemd — набора служебных компонентов для Linux-based операционных систем, совмещающего в себе функции системы инициализации, ведения журнала, управления сессиями пользователей и работы с контейнерами. Система инициализации systemd основана на модели зависимостей (в противовес событийной модели), производит отслеживание процессов запущенных сервисов при помощи механизма cgroups ядра Linux, поддерживает механизмы сокет- и dbus-активации сервисов и предоставляет удобный декларативный синтаксис для описания демонов и других сущностей. Это позволяет производить агрессивную параллелизацию при запуске и остановке сервисов.

В рамках проекта также разрабатывается ряд легковесных приложений и демонов, выполняющих второстепенные, но распространённые вспомогательные задачи (т. н. plumbing layer) — от настройки подсистемы VT (systemd-vconsole-setup) и первичного конфигурирования ОС (systemd-firstboot) до управления сетью (systemd-networkd) и UEFI-загрузчика (бывший gummiboot).

Данный релиз можно назвать в основном корректирующим — за исключением двух организационных изменений:

( читать дальше... )

>>> Объявление о релизе (lists.freedesktop.org)

И мы опять продолжаем.

В этой части серии мы попытались оценить устойчивость бинарного формата лог-файлов journald к произвольным повреждениям, испытали передачу логов по сети с одной машины на другую (нативным для journald способом), произвели настройку сетевого соединения на тестовой машине с помощью networkd/resolved и, наконец, продемонстрировали работу с D-Bus интерфейсами systemd и вспомогательных демонов (ради чего они, собственно, и были сделаны демонами).

Помимо видеоряда также имеется подробная текстовая аннотация.

Авторы: PaulCarroty, like-all, intelfx.

(В случае проблем с доступом к tlhp.cf также имеется зеркало.)

>>> Подробности (tlhp.cf)

21 мая был представлен очередной релиз системного менеджера systemd, совмещающего в себе функции системы инициализации, ведения журнала, управления сессиями пользователей и работы с контейнерами. systemd основан на модели зависимостей (в противовес событийной модели), производит отслеживание процессов запущенных сервисов при помощи механизма cgroups ядра Linux, поддерживает механизмы сокет- и dbus-активации сервисов и предоставляет удобный декларативный синтаксис для описания демонов и других сущностей. Это позволяет производить агрессивную параллелизацию при запуске и остановке сервисов.

( читать дальше... )

>>> Объявление о релизе (lists.freedesktop.org)

Добрый вечер, господа.

Предыстория: в процессе написания очередной новости про systemd я вконец задолбался и запилил конвертер маркдауна в LORCODE, выполненный в виде кастомного writer-модуля для pandoc на Lua. И оно даже работает и экономит мне дикое количество нервов. (Там требуется собирать нативный модуль для поддержки юникода для рисования табличек аскиартом, причём собирать требуется через зад, так что потенциальным тестерам рекомендуется выпилить функцию Table() и два импорта прямо над ней.)

Собственно, вопрос: как наиболее безгеморройно интегрировать эту штуку в Firefox, чтобы можно было писать комментарии прямо в маркдауне?

Господа, ни у кого нет конвертера чего-нибудь (маркдауна, HTML, ...) в лоркод? Да хоть из HTML на регекспах (да, я знаю, но всё же).

Алсо, когда ждать маркдауна? Вопрос к администраторам: генерация HTML из текста выполняется единовременно или при каждом отображении? А то можно пандок прикрутить.

$subj. Имеем очень интересный IM по имени matrix (https://matrix.org), который я бы описал как «взяли концепции электронной почты и без изменений перенесли в IM». Есть т. н. homeserver'ы (== «почтовые серверы»), на которых хранится история; есть клиенты, которые к ним подключаются.

«Комнаты» могут быть раскиданы по нескольким серверам. Есть адекватная синхронизация истории, есть адекватный мультилогин. Ах да, это всё немного похоже на Git: ведётся обмен не сообщениями, а состоянием и историей.

Есть референсный homeserver с веб-клиентом (synapse), есть клиенты для iOS и Android. Деплоить они его предлагают через б-гомерзкий virtualenv, но я опакетил под арч.

Anyone interested? Или, может быть, кто-то уже юзает?

UPD: join us at #lor:matrix.org.

Собственно.

Обновившись до .16, я заметил, что иксы у меня внезапно запущены от пользователя. Итак, награда «безжалостный убийца легаси» 2015 года достаётся GDM как первому дисплейному менеджеру, научившемуся это делать полностью из коробки. А сам он при этом рендерится — правильно, через вейланд.

К чему это я? GNOME3 ня. Эти чёртовы засранцы действительно умеют и могут.

Доброе утро, господа.

Дано:

• SATA SSD, одна штука (эффект наблюдается как минимум на OCZ Vertex 4 и LSS-16L6G, но, думаю, модель не имеет значения);
• любое ядро Linux вплоть до 4.0-rcчтототам.

Наблюдаем:

$ lsblk -D /dev/disk/by-id/ata-LITEONIT_LSS-16L6G_S0C41154Z1ZSCA185984
NAME   DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
sdb           0      512B       2G         0
├─sdb1        0      512B       2G         0
├─sdb2        0      512B       2G         0
└─sdb3        0      512B       2G         0

# hdparm -I /dev/disk/by-id/ata-LITEONIT_LSS-16L6G_S0C41154Z1ZSCA185984 | grep TRIM
	   *	Data Set Management TRIM supported (limit 8 blocks)
	   *	Deterministic read ZEROs after TRIM

Первая утилита забирает данные из /sys/block/sdX/queue (куда они помещаются драйвером дискового контроллера в ядре), вторая (AFAIK) — опрашивает контроллер напрямую.

Что не так:

Значения DISC-GRAN (размер erase unit'а) и DISC-ZERO должны быть равны 4K и 1 соответственно. Получается, что ядро не в состоянии узнать эти данные, хотя они на самом деле доступны (через другой интерфейс, видимо).

Вопрос:

Багу не нашёл, зарепортил. У кого-нибудь ещё такое наблюдается? Есть ли здесь специалисты по всему по ведру и разнообразным ATA, которые могут сказать, чем hdparm отличается от ядерного драйвера (и хотя бы примерно указать, куда копать)? Писать код руками умею, если что.

16 февраля был представлен очередной релиз системного менеджера systemd, совмещающего в себе функции системы инициализации, ведения журнала, управления сессиями пользователей и работы с контейнерами. systemd основан на модели зависимостей (в противовес событийной модели), производит отслеживание процессов запущенных сервисов при помощи механизма cgroups ядра Linux, поддерживает механизмы сокет- и dbus-активации сервисов и предоставляет удобный декларативный синтаксис для описания демонов и других сущностей. Это позволяет производить агрессивную параллелизацию при запуске и остановке сервисов.

В рамках проекта также разрабатывается ряд легковесных приложений и демонов, выполняющих второстепенные, но распространённые вспомогательные задачи (т. н. plumbing layer) — от настройки подсистемы VT (systemd-vconsole-setup) и первичного конфигурирования системы (systemd-firstboot) до управления сетью (systemd-networkd) и профилирования загрузки (systemd-bootchart).

Большая часть изменений, вошедших в этот релиз, была направлена на расширение возможностей по работе с контейнерами. Эти изменения сконцентрированы в компонентах systemd-machined и systemd-nspawn и нескольких сопутствующих утилитах.

Примечание переводчика: в плане новых контейнерных фич релиз получился крайне сырой; по факту мало что работает. Такое ощущение, что они тупо сделали промежуточный тарболл, чтобы заиметь чуть побольше тестеров.

( читать дальше... )

>>> Объявление о релизе (lists.freedesktop.org)

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

У нас было:

• два пакетика травы
• Микротиковский роутер (RB2011, если это важно)
• Торрентокачалка-файлопомойка-и-пульсовский-аудиосервер в одном лице (подключена по GbE)
• Энное (где N < 5) количество обычных смертных компьютеров (подключены по 802.11n)
• Один недоадмин в лице меня (knowledge of networking → 0)

Обычные смертные компьютеры хотят юзать скайп и периодически стримить музыку на аудиосервер. У них это не всегда получается (особенно стримить музыку), поскольку торренты мешают. Если кильнуть ktorrent или приостановить обмен данными, всё чинится.

Отсюда вопрос: как сделать так, чтобы торренты не мешали? KTorrent позволяет устанавливать значение DSCP для своего трафика.

Имеется некоторая внешняя железка (SATA-шный контейнер для хардов), подконнекченная к микромашинке с целью организации файлопомойки. Соответственно, стоит задача сделать её функционирование совершенно автоматическим. Всё бы ничего, но у железки есть одна неприятная особенность: после потери питания она не включается автоматически. Хотелось бы заставить её это делать.

Отсюда вопрос: если я впаяю параллельно кнопке включения (там обычная тактовая кнопка, без фиксации) резистор+конденсатор с R*C = 1..2, получится то, что мне нужно? Особенно в том плане, что заряду на конденсаторе нужно будет куда-то стечь после потери питания.

Доступен перевод «интервью» (точнее, треда на Reddit) с Леннартом Поттерингом, в котором он отвечает на различные вопросы посетителей сайта о разработке systemd, kdbus, PulseAudio и свободного ПО в целом, о дальнейших перспективах systemd, Linux и OSX, о реакции разработчиков на критику и о многом другом. Сохранён исходный стиль изложения.

Авторы перевода — PaulCarroty и intelfx.

>>> Текст перевода (tlhp.ml)

Вопрос к пользователям GNOME3 на экранах с большим разрешением. Как побороть размытые шрифты в Evolution и Empathy (и наверняка где-то ещё)? Такое ощущение, что оно рендерится с DPI 96, а потом растягивается в два раза.

• Evolution (тело сообщения)
• Empathy (окно чата)

...Тем временем, мы продолжаем.

В этой части акцент сделан на администрирование Linux-системы с помощью systemd: получение диагностической информации, управление юнитами, выполнение произвольных программ под управлением systemd, настройка процесса загрузки и его анализ. Показаны также примеры настройки «пользовательских» аспектов функционирования ОС: имени хоста, времени, даты, локали, раскладки клавиатуры. Авторы также постарались учесть критику и пожелания к первой части.

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

intelfx, like-all, PaulCarroty

>>> Текст (lhf-podcast.rhcloud.com)