Журнал Витуса. Голосов: 2 Адрес блога: http://vitus-wagner.livejournal.com/ Добавлен: 2008-02-19 12:48:41 блограйдером Lurk

Бытопись компьютерная.

2014-12-06 20:05:16 (читать в оригинале)

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

Ну прописать раздачу маршрута для сетки по dhcp это несложно.

Потом снес с него bind и поставил dnsmasq. Потому что я тщательно убираю с этого компьютера все серверные функции. Остались только почтовый (imap) сервер и точка терминирования vpn. Поэтому bind в качестве слейва у dnsmasq на точке доступа, который теперь основной DNS для локального домена - это явный overkill. А вот отдельные upstream-ы для отдельных vpn-сеток dnsmasq умеет явно лучше.

Теперь бы еще придумать способ рассказывать этому dnsmasq о вновь появляющихся хостах в vpn. Скрипт из которого рассказывать - есть. На vds-ке, которая теперь имеет возможность сходить на точку доступа через эту самую VPN и внутренний интерфейс.
Вариант

echo ip hostname >> /etc/hosts
killall -HUP dnsmasq 

в общем вполне рассматривается. Если удастся решить задачу
1. Как инициировать выполнение этого скрипта не давая выполняющему прав рута на точке доступа. То есть во-первых. у меня туда почему-то не работает ssh, только telnet, но даже если это пофиксить, не уверен, что dropbear, который там работает sshd, умеет все, что по этому поводу можно прописать openssh в authorized_keys.
2. Как убирать из /etc/hosts записи, для которых vpn положили. Ведь это может означать что через полчаса-час тот же хост возникнет в локальной сети и попроисит ip по dhcp. И тогда в dns-е ему уже должен соответствовать dhcp-шный ip.

Еще я таки добился нормальной (ну относительно) работы libvirtd с lxc и qemu/kvm одновременно. После очередного апгрейда libvirtd из бэкпортов. Оказалось, что можно в /etc/default/libvirtd включить опцию mount-cgroups=yes, и оно тогда будет правильно монтировать cgroups. Правда, пришлось вычистить из fstaba то что там раньше на эту тему было - оно неправильное. Ну и перегрузить машину в процесс несколько раз. Так что libvirtd той же версии, что и в jessie, живет без systemd.

Правда, выяснилось что та кривая система загрузки, которая сложилась у меня после неудачной попытки сделать загрузочным трехтерабайтник, требует ручной работы при апгрейдах ядра. Как бы это пофиксить? Смонтировать что-ли /work/boot на /boot с --bind?

То есть проблема такова:
На втором диске есть одна большая (терабайтная) партиция. Монтировать ее всю на /boot понятно не хочется - там много другого полезного есть. Но именно на ней стоит extlinux который грузит систему.

Есть, конечно, вариант, скопировать все с терабайтника на трехтерабайтник (в /home есть для этого свободное место) и отгрызть маленькую партицию для честного /boot. Но ломы... Правда, зато и свопа можно будет прибавить. А то там своп-раздел всего 4Гб.

Или наоборот, убрать этот своп-раздел. сделать на его месте /boot, а своп хрен с ним, пусть будет только на трехтерабайтнике.

This entry was originally posted at http://vitus-wagner.dreamwidth.org/1032105.html. Please comment there using OpenID. Now there are comments