from:"Victor Wagner"

On Thu, 11 Oct 2018 16:09:51 +0500
Stanislav Vlasov  wrote:

> 11.10.2018, Victor Wagner написал(а):
> >> Руками - это Centos и т.п., для которых работающего аналога
> >> debootstrap не обнаружено.
> >> Ну и, к тому же, этот самый эталонный qcow2 тоже надо генерить
> >> перед использованием, так как apt-get upgrade в мастер-образе
> >> может дать не такой же результат, как генерация с нуля.
> 
> > По-моему, если делать apt-get dist-upgrade, то разница будет
> > пренебрежимо мала. Во всяком случае, если речь идет о stable,
> > oldstable и Ubuntu LTS.
> 
> Верно, но у нас не только убунты c дебианами.
> Тут заодно решалась задача унификации создания мастер-образов, так как
> часть образов - генерилась автоматически, часть - приходилось
> делать/обновлять руками.
> 
> > Впрочем, лично я считаю что "генерировать с нуля перед
> > использованием" это категорически неправильный подход.
> 
> Не "перед использованием", а "раз в сутки" всё же.
> Это ж сколько заняло бы развёртывание виртуалки, если б её через
> debootstrap ставили...
> А так - раз в сутки создаются три десятка образов.

Что? У вас "использование" занимает существенно меньше суток?

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

Мы - фирма необычная, мы кроссплатформной разработкой занимаемся 
(а судя по тому что я вижу в тенденциях развития софта, обычные люди
очень хотят забыть, что бывают архитектуры, кроме amd64 и операционки
кроме Linux). 

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

> Ну и, кстати, apt-get update && apt-get upgrade там, где требуется
> именно новая система без следов обновлений - может быть неверным
> решением.

Я полагаю, что требование "новой системы без следов обновления"
является ошибкой при постановке технического задания.

> Но это уже местные особенности.
>

Re: LXC vs Docker и форматы контейнеров

On Thu, 11 Oct 2018 12:40:56 +0300
Alexander Gerasiov  wrote:

> Hello Victor,
> 
> On Thu, 11 Oct 2018 07:40:19 +0300
> Victor Wagner  wrote:
> 
> > Решение на базе LXC или LXC+Ansible здесь может оказаться проще
> > потому что не надо приноравливаться к тому как сделали разработчики
> > докера, а можно сделать как кажется нужным в конкретной ситуации.
> > LXC-низкоуровневый конструктор, этим и плох, этим и хорош.
> 
> Я рекомендую LXD: он чуть более высокоуровневый и очень приятный в
> плане баланса между простой интерфейс/возможности по кастомизации.
> Единственная проблема - ставится пока только из snap.
> 
Ну во-первых, не только из snap. В убунтах он есть в виде нормальных
пакетов, соответственно можно взять исходники и спортировать.

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

Но вообще интересно то, что LXD написан на Go. А авторами этого языка в
саму концепцию средств разработки на нем заложена та же идея, что и в
snap - максимальная изоляция приложения от окружающей системы.

Поэтому идея заворачивания go-приложения в snap уже выглядит какой-то
подозрительной.
--

Re: LXC vs Docker и форматы контейнеров

On Thu, 11 Oct 2018 13:02:34 +0500
Stanislav Vlasov  wrote:

> 11.10.2018, Victor Wagner написал(а):
> >> Более того, у нас на работе мастер-образы для виртуалок в kvm
> >> создаются на базе соответствующих образов докера путём доустановки
> >> нужных пакетов в распакованном chroot.  
> [...]
> 
> > Честно сказать не понимаю, зачем мастер-образы делать таким
> > способом. По-моему проще эталонный qcow2 файл скопировать, и потом
> > уже доустанавливать пакеты и настраивать сеть каким-нибудь ansible.
> > Тем более что это будет работать не только с линуксаии, но и с
> > freebsd, solaris и даже windows.  
> 
> Поэтому:
> >> Это оказывается быстрее и удобнее, чем debootstrap и тем более, чем
> >> руками.  
> 
> Руками - это Centos и т.п., для которых работающего аналога
> debootstrap не обнаружено.
> Ну и, к тому же, этот самый эталонный qcow2 тоже надо генерить перед
> использованием, так как apt-get upgrade в мастер-образе может дать не
> такой же результат, как генерация с нуля.

По-моему, если делать apt-get dist-upgrade, то разница будет
пренебрежимо мала. Во всяком случае, если речь идет о stable, oldstable
и Ubuntu LTS.

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

Скажем, для сборочных систем у нас используется цепочка докерных
образов - мастер-образ (с докерхаба, если там соотвествтующихй
дистрбутив есть)- сборочный образ с уже установленными всеми
build-dependencies- рабочий контейнер.

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

Re: LXC vs Docker и форматы контейнеров

On Thu, 11 Oct 2018 11:02:17 +0500
Stanislav Vlasov  wrote:

> 11.10.2018, Victor Wagner написал(а):
> 
> > 4. Поиграться с готовыми образами систем/приложений. Вот тут докер
> > вне конкуренции. Потому что у него есть DockerHub где этих образов
> > море. Хотя тут уже надо смотреть в сторону убунтовских snap.
> > Видимо, в ubuntu эту технологию стали развивать когда уткнулись в
> > ограничения докера.  
> 
> Более того, у нас на работе мастер-образы для виртуалок в kvm
> создаются на базе соответствующих образов докера путём доустановки
> нужных пакетов в распакованном chroot.
> Это оказывается быстрее и удобнее, чем debootstrap и тем более, чем
> руками. Ну и окончательная конфигурация (хостнейм, сеть, пароли,
> ключи) создаётся после раскатывания образа при помощи runc.

Мне чаще приходится сталкиваться с обратной задачей - поставив в
виртуалку какой-нибудь дистрибутив родным инсталляторм, сделать из
этого докер-образ. 

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

Честно сказать не понимаю, зачем мастер-образы делать таким способом.
По-моему проще эталонный qcow2 файл скопировать, и потом уже
доустанавливать пакеты и настраивать сеть каким-нибудь ansible.
Тем более что это будет работать не только с линуксаии, но и с freebsd,
solaris и даже windows.

C другой стороны, мне много виртуалок не нужно. У меня сейчас примерно
4 десятка поддержвиваемых дистрибутивов/систем, и на каждую нужно от
силы пяток экземпляров
1. В билдферме для тестирования кода, принимаемого от разработчиков
2. Для сборки пакетов
3. Для тестирования собранных пакетов
4,5. Для выполнения всяких длительных тестов

--

Re: LXC vs Docker и форматы контейнеров

2018-10-10 Пенетрантность Victor Wagner

В Thu, 11 Oct 2018 01:29:09 +0300
Oleksandr Gavenko пишет:

> Всевозможные User-mode Linux, OpenVZ, Xen и т.д. я пропустил. Его
> нужно было либо на голом железе крутить или с особыми ядрами. В общем
> VistualBox можно кликать, экономя время и мозги.
>

Правильно поставленный вопрос - это больше половины ответа. У докера
есть своя область применения, у LXC-своя. А есть вещи (вроде того же
запуска skype) для которых LXC - это избыточно тяжеловесное решение, и
надо испольовать что-то типа firejail или chroot.

К сожалению, из огромного письма, перечисляющего разные свойства
технологий (в которые почему-то вместе с технологиями изоляции и
виртуализации попали технологии массового управления системами -
ansible и CFEngine) я так и не понял чего хочется получить.

Кроме того я не понял в чем сложности с настройкой бриджа-то? Вещь
исключительно простая и прямолинейная.

Итак, что может хотеться получить:

1. Обеспечить работу недоверенных приложений, возможно нескольких
взаимодействующих, возможно предъявляющих несовместимые требования к
операционным системам, в которых развернуты.

Под эту задачу создавался докер. И ее худо-бедно решает. В смысле как
только в список несовместимых требований попадает "это приложение у нас
32-разрядное", становится худо.

При этом надо понимать, что если вы ходите что-то серьезное хостить, то
"сэкономить время и мозги" не получится. Придется достигать глубокого
понимания как работает докер (а он заметно overengineered), как решать
проблемы, которые он не решает (например защиту данных от
несанкционированного изменения при взломе приложения, которое вообще-то
имеет право в эти данные писать).

Решение на базе LXC или LXC+Ansible здесь может оказаться проще потому
что не надо приноравливаться к тому как сделали разработчики докера, а
можно сделать как кажется нужным в конкретной ситуации.
LXC-низкоуровневый конструктор, этим и плох, этим и хорош.

2. Обеспечить разработку и тестирование программы на возможно широком
спектре дистрибутивов Linux при ограниченных аппаратных ресурсах.
Вот здесь, на мой взгляд, LXC гораздо лучше. Хотя на практике часть
тестовых систем все равно приходится держать в KVM, несмотря на
его более высокий оверхед поскольку необходимо бывает тестироваться с
их родными ядрами. Какой-нибудь Oracle Linux unbreakable kernel или
Astra Smolensk с ее мандатным доступом.

3. То же что и 2, но поддерживаемых линуксов меньше десятка, а основной
упор в переносимости надо делать на системы с другими ядрами. Тогда
проще не париться и все держать в KVM/VirtualBox/VMWare. Необходимость
менеджить две системы изоляции/виртуализации обойтется дороже, чем
оверхед от загоняния в виртуальную машину того, что могло бы жить в
контейнере.

4. Поиграться с готовыми образами систем/приложений. Вот тут докер вне
конкуренции. Потому что у него есть DockerHub где этих образов море.
Хотя тут уже надо смотреть в сторону убунтовских snap. Видимо, в ubuntu
эту технологию стали развивать когда уткнулись в ограничения докера.

--
Victor Wagner

Re: devel_website_examples

2018-10-08 Пенетрантность Victor Wagner

On Mon, 08 Oct 2018 09:15:00 +0300
Galina Anikina  wrote:

> Прочитала - посмотрите кое-что-
> 
> https://www.debian.org/devel/website/examples
> 
> "В качестве примера будет использоваться французский язык:"
> 
> Почему здесь не сделать в качестве примера русский?

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

Хотя с этой точки зрения испанский, пожалуй, был бы лучше. На нем вся
Латинская Америка говорит. Поэтому, скорее всего он и для жителя США
понятнее, чем француский.

А с точки зрения чистой филологии красиво было бы в качестве
альтенативного языка в примерах использовать латынь.

--

Re: Доступ к медиатеке

2018-10-07 Пенетрантность Victor Wagner

On Sat, 6 Oct 2018 21:15:36 +0300
artiom  wrote:

> > Интересно, какие по вашему мнению способы использования данных
> > гуглем хуже таржетированной рекламы? 
> >   
> 
> Не секрет, как они используют данные и какие:
> https://privacy.google.com/intl/ru/take-control.html?categories_activeEl=sign-in
> 
> Одна из проблем, которую уже освещали, не таргетированная реклама, а
> таргетированный контент. Вплоть до того, что некто может не узнать
> важных новостей по своему запросу.

Согласен, таргетированный контент хуже таргетированной рекламы. Поэтому
я использую по умолчанию в качестве поисковой машины duckduckgo, а не
google.

> Потом, ещё это: "Иногда мы получаем запросы на доступ к данным
> пользователя от правоохранительных органов. Наши юристы рассматривают
> каждый запрос и отвечают отказом, если он составлен в слишком общих
> терминах или с нарушением юридических норм."
> 
> Рассматривают и предоставляют. Как известно, законы везде разные.
У гугля есть регулярно публикуемые transparency report-ы, где они 
указывают количество запросов от правоохранительных органов и количество
удовлетворенных среди них. С разбивкой по странам.

> 
> Плюс, ваши данные потенциально могут утечь:
> https://tproger.ru/news/facebook-87-million-leak/
> 
> Если возможно на Facebook, то почему не в гугле? К тому же,
> google.docs были недавно яндексом проиндексированы.

В данном случае (мы же обсуждали проблему попадания некоего нашего
публичного сайта  в поисковый индекс гугля) это нерелевантно.

В случае использования Google Docs и Google Drive тут риски все те же,
что и в любых облаках. Правда, размер имеет значение. В случае
возникновения у гугля конфликта с роскомнадзором проблема, скорее
всего, будет быстро решена. Вот они уже и  с китайцами договорились,
хотя несколько лет бодались.

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

Re: Доступ к медиатеке

On Sat, 6 Oct 2018 15:49:18 +0300
artiom  wrote:

> 
> Т.е., всё-таки на первое место выходит доступность, а
> конфиденциальность данных на втором, и они не сильно чувствительны к
> этой угрозе?

Проблема тут не в том, сильно ли чувствительны данные к угрозам
конфиденциальности, а в том что разные данные к ним чувствительны очень
по разному.

Нарушая фидошную традицию и вспоминая, что написано в subj, а там
написано "Доступ к медиатеке", мы можем рассмотреть угрозы
конфиденциальности для данных медиатеки.

В медиатеке у нас лежат данные, которые вообще в принципе опубликованы,
и которые потенциальному атакующему доступны и из другого места.

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

Насколько я понимаю, закрытие любой самой примитивной аутентификацией
во-первых отсекает 100% ботов, которые рыщут по интернету в поисках
нелегальных копий копирайченной продукции, во-вторых, является
достаточно хорошей отмазкой в случае если наезд таки произойдет. Мы
данные не распространяем, мы их для собственных нужд на этом сервере
держим. И даже доступом к нему не торгуем. А так все это добросовестно
приобретенные фильмы.

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

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

> > Потому что первым в списке угроз "будет плохо, если они прочитают
> > ваши данные" стоит гугль, который использует данные для
> > таржетированной рекламы.  И при этом существует достаточно много
> > данных, которые их владельцы старательно скармливают гуглю, чтобы
> > они попали в результаты поиска.
> >   
> 
> Он использует эти данные не только для рекламы.
> 
Интересно, какие по вашему мнению способы использования данных гуглем
хуже таржетированной рекламы?

Re: nginx и проксирование

On Sat, 6 Oct 2018 17:56:30 +0300
artiom  wrote:

d
> > Из того, что каждый сервис будет иметь свой собственный внешний
> > (видимый клиентам) хостнейм, никак не следует что пользователей
> > будут по этому хостнейму пускать на сервис напрямую, минуя общий
> > для всех сервисов фронтенд-прокси.
> >   
> 
> Хм... Т.е., я завожу в своей зоне ещё три домена. При обращении к ним,

Не домена, а хоста. И все их A-записи указывают на один и тот же
IP-адрес - тот, на котором nginx. В конфиге у nginx пишем, что если к
нему пришли, указав в http запросе такой-то хостнейм, проксируем на
такой-то сервис.

Обратная прокси будет одна. И слушать будет на одном IP-адресе и одном
порту. Просто в этот IP-адрес будет резолвится несколько имен, и на
основании того имени, к которому обратился клиент (и честно указал это
в HTTP запросе, как это позволяет HTTP/1.0 и безусловно требует
HTTP/1.1) nginx будет решать куда именно проксировать прошедший
авторизацию запрос.

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

> меня перекидывает на ещё один обратный прокси, который делает проброс
> только если пользователь авторизован?
>

Re: Доступ к медиатеке

On Sat, 6 Oct 2018 12:59:41 +0300
artiom  wrote:

> 05.10.2018 23:06, D. H. пишет:
> > On 05/10/18 02:45 PM, artiom wrote:  
> >> А от кого вы защищаться собрались?  
> > 
> > Как правильно было сказано уже не помню где. Но суть примерно такая:
> > 
> > - Вам есть что скрывать?
> > - Нет, но мои данные не ваше дело.
> >   
> Не в тему.
> Вопрос совершенно конкретный: "От кого вы собрались защищаться?"
> Если вы этого не понимаете, то как вы определите перечень мер защиты?

Защищаться надо

1. От пьяного тракториста, который переедет интернет кабель
2. От обкурившегося сетевого админа, который сломает роутинг.
3. От очередной драчки роскомнадзора с Дуровым при которой ваше облако
может случайно попасть под раздачу, оказавшись в одном /16 блоке с
телеграмовской прокси.
4. От bingbot-а, который запросто может устроить DoS атаку вашему сайту.

От этих угроз (угроз доступности) следует защищать ЛЮБЫЕ данные.

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

Потому что первым в списке угроз "будет плохо, если они прочитают
ваши данные" стоит гугль, который использует данные для таржетированной
рекламы.  И при этом существует достаточно много данных, которые их
владельцы старательно скармливают гуглю, чтобы они попали в результаты
поиска.

Re: nginx и проксирование

On Sat, 6 Oct 2018 12:56:42 +0300
artiom  wrote:

> 05.10.2018 22:54, Victor Wagner пишет:
> > В Fri, 5 Oct 2018 22:32:47 +0300
> > artiom  пишет:
> >   
> >> Да, nginx ни в чём, ни в чём не виноват.
> >> Это на странице прописано включение css от корня и браузер,
> >> соответственно, делает GET запрос.
> >> Вопрос, как сделать, не заводя корень, и возможно ли это?  
> > 
> > А подумать? Вот у нас есть поток данных, идущих от сервера к
> > браузеру через proxy.
> >   
> Вот через подумать и выходит, что технически это возможно.
> 
> > Вот где-то внутри этого потока данных js-код, формирующий URL
> > запроса. По-моему, очевидно, что прошерстить весь этот код и
> > выловить URL, чтобы их переписать - задача в общем виде не
> > разрешимая.
> >Так и не требуется. Достаточно подменить PUT/POST/GET/etc.,
> >обращающиеся  

Где подменить? На клиенте?  На proxy-то не получится.

Вот у вас есть два сервиса, каждый из
которых считает что он в корне сайта, и формирует URL на свои кнопки
как /images/something.gif.  

Вот приходит к вам на прокси запрос  GET /images/something.gif.

Как вы определите, его надо переписывать
на /service1/images/something.gif
или на /service2/images/something.gif?

> к /bla/bla/... на BASE_URL/bla/bla/...
> 
> > Если же у нас код дошел до браузера неизменным, то браузер отправит
> > на прокси ту URL, которую ему отдал сервер. И определить от какого
> > из проксированных сервисов эта URL тоже будет ох как непросто.
> > 
> > Раз задача в общем виде неразрешимая, то решать ее придется в
> > частных случаях, для каждого из сервисов по отдельности,
> > конфигурируя каждый сервис (если он это позволяет) на работу под
> > уникальным префиксом, причем совпадающим с тем, что был указан нв
> > фронтэнде. 
> Ага, это при том, что я пытаюсь общую авторизацию LDAP припилить к
> сервисам, в которых её нет.
> 
> >   
> >> У меня уже этих доменов штук 7, а здесь не Transmission, а сразу
> >> три  
> > 
> > Да хоть сотня. Жалко их что ли? Этот ресурс нелимитированный.
> > Расходуются только строчки в файле зоны локального DNS.
> >   
> Не особенно удобно. А в случае с сервисами, авторизуемыми по LDAP
> через nginx это не вариант. Мне же их надо внутри держать, а запрос
> проксировать лишь тогда, когда авторизация прошла.

Почему не вариант? Вариант. Вы заводите В nginx name-based
virtualhost, и его проксируете весь. Так что запрос 
https://externalname/static/image.gif проксируется в 
http://internalcontainerip:port/static/image.gif. Т.е. меняется при
проксировании адрес  nginx на адрес контейнера (или на localhost, если
сервис крутится на той же машине, что и nginx. А та часть URl,которая
следует за именем хоста - не меняется.

Можно еще извернуться так, чтобы контейнер с сервисом считал что то
имя, под которым вся сеть видит виртуальный хост на nginx - это его имя

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

--

Re: Доступ к медиатеке

В Fri, 5 Oct 2018 16:12:50 +
Коротаев Руслан  пишет:

> Victor Wagner  пишет:
> 
> > Каналий-посредников можно ограничить ролью канальных провайдеров. И
> > доверять им не данные, а только передачу шифрованных пакетов.  
> 
> Если данные зашифрованы, почему бы не доверить им хранение. Главное
> организовать безопасную передачу ключей и параметров доступа.

Потому что данные нужно защищать в первую очередь не от того, чтобы они
стали доступны другим, а от того, чтобы они стали недоступны вам.

Если данные хранятся на вашей домашней машине у вас намного больше
шансов что удастся до них добраться тогда. когда это перестанет
возможным делать штатным образом.


> 
> > Когда-то давно, примерно с 2001 до 2015 у меня домашняя машина была
> > доступна из интернета. И в случае срабатывания intrusion detection
> > последоватлельность действий была 
> > 1. Отключить сетевой кабель
> > 2. Загрузиться с rescue cd
> > 3. Разбираться.  
> 
> Вы же в курсе, что те, у кого есть физический доступ к вашей домашней
> машине могут сделать тоже самое. А что делать тем, кому вы лично дали

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

> доступ к вашим данным? Ждать пока вы разберетесь, тогда это трудно
> назвать качественным сервисом.

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

Учитывая то, что у меня данных мало, а у него - много, у него WAL-ы
дольше накатываться будут, чем у меня вся процедура восстановления
пройдет.
 



-- 
   Victor Wagner

Re: nginx и проксирование

В Fri, 5 Oct 2018 22:32:47 +0300
artiom  пишет:

> Да, nginx ни в чём, ни в чём не виноват.
> Это на странице прописано включение css от корня и браузер,
> соответственно, делает GET запрос.
> Вопрос, как сделать, не заводя корень, и возможно ли это?

А подумать? Вот у нас есть поток данных, идущих от сервера к браузеру 
через proxy.

Вот где-то внутри этого потока данных js-код, формирующий URL запроса.
По-моему, очевидно, что прошерстить весь этот код и выловить URL,
чтобы их переписать - задача в общем виде не разрешимая.

Если же у нас код дошел до браузера неизменным, то браузер отправит на
прокси ту URL, которую ему отдал сервер. И определить от какого из
проксированных сервисов эта URL тоже будет ох как непросто.

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


> У меня уже этих доменов штук 7, а здесь не Transmission, а сразу три

Да хоть сотня. Жалко их что ли? Этот ресурс нелимитированный.
Расходуются только строчки в файле зоны локального DNS.

> сервиса висит за LDAP авторизацией через nginx

Вот как раз transmission прекрасно работает с указанием префикса.

Там единственное, что нужно сделать кроме проксирования
/transmission/ это перманентный редирект /transmisson
на /transmission/web.




-- 
       Victor Wagner

Re: nginx и проксирование

On Fri, 5 Oct 2018 01:50:55 +0300
artiom  wrote:

> В Docker-контейнере крутится nginx, который при обращении по
> определённому пути перенаправляет запрос к сервису во внутренней сети.
> 
> Например, так:
> 
> location /youtube-dl/ {
> #auth_request /auth-proxy;
> proxy_pass http://youtube-dl-webui:5000/;
> }
> 
> Т.е., фактически, работает, как обратный прокси. Но сервисы
> предоставляют Web интерфейс и хотят отдавать статику.
> 
> Я обращаюсь к youtube-dl-webui:
> 
> https://NAS/youtube-dl/
> 
> youtube-dl-webgui загружает CSS, начиная от корня: "GET
> /static/css/global.css HTTP/1.1" 404
> 
> Ну и, естественно, получает 404.
> Как сделать проксирование так, чтобы сервисы обращались по нужному
> адресу?

Я бы сказал, что nginx тут не виноват. Существует слишком много
способово запросить URL-ку, чтобы их можно было все перехватить и
поправить при отдаче страницы наружу.

Поэтому если сервис хочет корня, ему надо дать корень.

Завести name-based virtual host на нем отдавать куда надо всё.

Re: Доступ к медиатеке

On Fri, 5 Oct 2018 13:36:29 +
Коротаев Руслан  wrote:

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

Каналий-посредников можно ограничить ролью канальных провайдеров. И
доверять им не данные, а только передачу шифрованных пакетов.

Когда-то давно, примерно с 2001 до 2015 у меня домашняя машина была
доступна из интернета. И в случае срабатывания intrusion detection
последоватлельность действий была 
1. Отключить сетевой кабель
2. Загрузиться с rescue cd
3. Разбираться.

Сейчас, с тех пор как у моего провайдера появился IPv6, моя домашняя
машина опять доступна из той части интернета, где есть IPv6.

Re: Доступ к медиатеке

On Fri, 5 Oct 2018 12:30:44 +0300
Igor Savluk  wrote:

> А есть подобная вещь но не на PHP?

Ну вот Apache CloudStack есть - на java.
Правда, не знаю насколько он подобный.
Но вроде storage management там есть.

--

Re: Доступ к медиатеке

On Fri, 5 Oct 2018 09:01:46 +0300
artiom  wrote:

> 1.  Windows клиентов пока нет. Но, в идеале, не хотелось бы
> привязываться к ОС. SSHFS есть почти везде, браузер - ещё лучше.

sshfs нет почти нигде. В windows нет, в андроиде - нет.
Насчет MacOS не уверен, надо у коллег поспрашивать. Про экзотику типа
Solaris я и не говорю.

webdav это не браузер (возможно к сожалению).  То есть браузером в
лучшем случае получится читать файлы (если кто мне расскажет про плагин
к файрфоксу, превращающий его в файлменеджер для dav-сайта, буду
благодарен). А писать - либо davfs2, либо cadaver, либо какой-нибудь
файлменеджер.

> 2. SAMBA - не вариант. Потому что, одна из основных задач - работа с
> данными через Интернет.

Это как раз то, для чего лично я использую webdav. Для менеджмента
файлов на сервере, располженном на хостинге. 

> 3. С LDAP тоже есть некоторая проблема. Сервер доступен, как plain без
> шифрования трафика, но только в сети машины. Т.е., я могу к нему
> обратиться с локалхоста, из докер-контейнеров, но снаружи запросы не
> приходят.

А в общем и не надо. LDAP должен быть доступен серверному софту.
А клиент взаимодействует с сервером  прикладного протокола. 
Чай не Kerberos.

> 
> Но, похоже, что WebDAV - вполне себе решение, смотрю.

Крайне рекомендую задуматься над тем, чтобы использовать digest
authentication. Я правда сходу не понял, как в Apache подружить
mod_auth_digest и mod_authnz_ldap. А в nginx я вообще не очень
разбираюсь. Но точно знаю что по крайней мере с basic auth webdav в
nginx с LDAP работает.

В перспективе расширения списка клиентских платформ это бы очень
пригодилось.

--

Re: Доступ к медиатеке

2018-10-04 Пенетрантность Victor Wagner

В Thu, 4 Oct 2018 20:44:38 +0300
artiom  пишет:

> Требуется организовать доступ к медиатеке, позволяющий нескольким
> пользователям переименовывать, удалять и, главное, добавлять файлы.
> 
> Медиатеку показываю, используя Emby, но с добавлением там всё плохо,
> а о полноценном управлении, как файловой структурой, и говорить
> нечего.
> 
> При этом, условие такого, что пользователи авторизуются через LDAP.

Я бы использовал webdav. С ним прозрачно работают файловые менеджеры,
причем не только в Linux, есть разнообразные командно-строчные
клиенты, его можно примонтировать через davfs.

Ну и доступ управляется средствами веб-сервера. 

Правда, с LDAP тут есть
одна небольшая проблема - если есть windows-клиенты, то нужно либо
использовать digest аутентификацию (у windows, как всегда, свое
представление о security), либо править всем клиентам реестр.

Еще можно раздать с помощью samba. Там тоже гибкости хватает, чтобы
сделать возможность нескольким пользователям ходить на разделяемый
ресурс с одним UID. Но вот ни разу не прикручивал к samba внешний LDAP.



-- 
           Victor Wagner

Re: Файлы

2018-08-27 Пенетрантность Victor Wagner

В Mon, 27 Aug 2018 23:00:58 +0300
artiom  пишет:

> ЫЫЫ: "Subordinate user/group ids appear in Linux kernel 3.12 in 2013."
> 
> Что это я понял. Но для чего это не вполне понятно не только после
> прочтения man, но и после прочтения док, даже то, что "для LXC" не
> сильно прояснило ситуацию.
> Русским языком можете объяснить, зачем эта штука появилась?

Чтобы позапутаннее было. Система namespace в ядре это "лошадь,
изобретенная комитетом". Помнится, в свое время там была такая борьба
самолюбий между Parallels, RedHat и еще несколькими компаниями на тему
того, как правильно делать контейнеры. В результате получилось
несколько эклектично.

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

Только вот ни разу не попадались описания того, что кто-то это
используют. 

Обычно все запускают какой-то демон от рута - docker там или libvirtd,
и он уже рулит контейнерами. А наличие в разных контейнерах процессов с
одинаковыми uid никого не волнует.

-- 
   Victor Wagner

Re: разобрать и собрать initrd

2018-08-22 Пенетрантность Victor Wagner

On Wed, 22 Aug 2018 04:11:31 +0300
sergio  wrote:

> А как в этом нашем дебиане разобрать initrd (что бы поменять в нём
> файл) и собрать обратно?
> 
> 

Наскоько я понимаю, вопрос не в том "как разобрать", а "как сделать
так чтобы при последующей перегенерации initrd при апгрейде ядра или
еще какого пакета, который что-то в initrd кладет, измененный файл бы
оттуда не пропал".

Re: DD-WRT и 4G модем

2018-06-14 Пенетрантность Victor Wagner

On Thu, 14 Jun 2018 15:26:59 +0300
Eugene Berdnikov  wrote:


> 
> > Настроить фильтрацию пакетов через ebtables можно и в режиме
> > бриджа.  
> 
>  В ebtables нет самого главного элемента современных пакетных
> фильтров - трекера коннекций, который conntrack. Поэтому ebtables как
> ip-фильтр стоит на уровне ipchains, которому 20 лет уж царствие
> небесное... :)

Никто не мешает и iptables использовать. Для того что ip.

sysctl -w net.bridge.bridge-nf-call-iptables=1

ebtables на мой взгляд. в данном случае в основном нужны, чтобы
зарезать то, что не IP, и чему через наш бридж ходить не надо.
--

Re: DD-WRT и 4G модем

2018-06-14 Пенетрантность Victor Wagner

On Thu, 14 Jun 2018 14:55:36 +0300
Alexander Danilov  wrote:


> > два DCHP? Или получилось настроить роутер, чтобы он тупо бриджил
> > пакеты от свистка во локальную сеть?  
> 
> Я сильно подозреваю, что у модема внутри linux. Это обычное дело для
> таких девайсов. Да, там 2 ната получается и меня это нисколько не
> напрягает. А вот бриджить пакеты от свистка я бы не рекомендовал -
> обновить прошивку на роутере в случае обнаружение проблем с
> безопасностью значительно легче, чем искать исправленную прошивку для
> модема.

Вообще говоря, не надо думать 
1. Что NAT автоматически обеспечивает безопасность.
2. Что его разумно использовать для обеспечения безопасности.

Настроить фильтрацию пакетов через ebtables можно и в режиме бриджа.


--

Re: DD-WRT и 4G модем

2018-06-14 Пенетрантность Victor Wagner

On Thu, 14 Jun 2018 13:50:48 +0300
Alexander Danilov  wrote:

> через wifi - на 2g перескакивало только 1 раз. Думаю со временем
> перенести маршрутизатор на чердак - надо только понять, как бы зимой
> от переохлаждения не померла. На чердаке ловится стабильно 4g. Модем
> не перешивал. Маршрутизатор перешил, ибо оригинальная не понимала usb

У меня точка доступа ASUS WL500g десять лет прожила в неотапливаемой
мансарде. Правда, постоянно зимой в том доме никто не жил, но на зимние
каникулы регулярно наезжали и интернетом пользовались, в том числе и в
30 градусные морозы.

--

Re: env DISPLAY

2018-06-01 Пенетрантность Victor Wagner

On Fri, 1 Jun 2018 10:37:40 +0300
Andrey Nikitin  wrote:

> В Fri, 1 Jun 2018 10:01:32 +0300
> Иван Лох  пишет:
> 
> > Нет. Один из них — X сервер обслуживающий gdm, а другой
> > пользовательский.  
> 
> О, точно, но DISPLAY у него такой же
> 
> $ sudo -u Debian-gdm sh -c 'echo $DISPLAY'
> :1
> 

Вообще говоря, конкретная X-овая программа совершенно не обязана
коннектиться к тому (или только к тому) дисплею, на которую указывает
переменная DISPLAY. Очень многие программы имеют параметр командной
строки -display (в X Intristic toolkit) или --display (в gtk), а
некоторые вообще умеют с несколькими дисплеями работать.

Вот например, в tk можно создать новое toplevel окно, указав ему на
каком дисплее появляться.

Re: комп с блютозом в деревне, где есть мобильная связь

2018-05-24 Пенетрантность Victor Wagner

On Thu, 24 May 2018 14:02:32 +
fuf  wrote:

> Ещё побеспокою.
> Цитаты я сам в новое чистое сообщение вклеиваю из ваших постов с
> debian-russian@lists.debian.org.
> Телефон у меня примитивный NOKIA, я думаю никакой поддержки там нет.

Там блютуз вообще есть? Если есть, включается bluetooth в нем и в
компе, берется sdptool и с его помощью смотрится какие именно профайлы
поддерживает этот телефон. Почти наверняка DUN там будет.

Помнится в прошлом десятилетии у Nokia были модели стоимостью порядка
100 долларов, которые вполне работали в качестве блютуз-модема.
Я правда, тогда раскошелился на 3109 Classic. Про него тоже многие
скажут, мол, "примитивный, даже фотоаппарата нет".

> Значит нужен новый?

Если нужно новое устройство, то лучше покупать usb-модем или wifi
роутер. Стоит будет вряд ли дороже минимального телефона с требуемой
функциональностью, а удобства будет больше.

Re: комп с блютозом в деревне, где есть мобильная связь

2018-05-24 Пенетрантность Victor Wagner

On Thu, 24 May 2018 11:07:13 +
fuf  wrote:

> Опять я.
> Осмысливаю советы, больше всего подошло бы:
> --- При наличии умения пользоваться дебианом и работоспособного в
> нем блютуса в дебиане (такое бывает не всегда, иногда встроенные
> контроллеры линуксом не поддерживаются) цена доп. железа 0. Но
> телефон во время работы в инете должен быть рядом с ноутом. - ,
> а если не получится то:
> ---а. Выделить для этой цели отдельную сим-карту, каковую
> вставить в модем в ПК ---.
> Я правильно понял, что тел. может быть любой (в первом случае) ?,

Не любой, а с поддержкой bluetooth и без поддержки Wi-Fi (потому что
если есть поддержка wi-fi, то лучше ей пользоваться)

> и что сим-карта обычная, как в тел-не (во втором случае) ?

Тут есть нюансы. Если сим-карту покупать специально под эту задачу, надо
внимательно смотреть на доступные в регионе тарифные планы операторов.
Достаточно часто бывает что есть тариф, который не слишком удобен в
телефоне, но существенно более экономичен в модеме или роутере.

Впрочем, физически сим-карты одинаковые, а  тарифы можно переключать
online на сайте оператора.

> Спасибо.

Re: комп с блютозом в деревне, где есть мобильная связь

2018-05-24 Пенетрантность Victor Wagner

On Thu, 24 May 2018 08:16:08 +0200
 wrote:

> Я пользуюсь мобильным роутером
> http://otzovik.com/reviews/3g_wifi_router_huawei_e5330/
> Не уверен, что это лучшее устройство этого типа.
> Для меня важно, что роутер умеет подключаться через мобильную связь а
> также раздавать имеющуюся WiFi-сеть уже от своего имени.

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

А здесь человек явно пытается слепить беспроводную сеть из того, что
было.

Не уверен, что результат его обрадует, но интересный опыт - получит.

--

Re: комп с блютозом в деревне, где есть мобильная связь

2018-05-23 Пенетрантность Victor Wagner

В Thu, 24 May 2018 06:37:38 +0300
Dmitry Alexandrov <321...@gmail.com> пишет:

> fuf <fufl...@gmail.com> wrote:
> > Просветите, что необходимо для работы компа с блютозом в деревне
> > где есть мобильная связь  
> 
> Э...  Электричество?  :-)
> 
> > Кроме компа с блютузом имею старый мобильник.  
> 
> Так, кажется, надо включать телепата и догадываться, что речь о
> подключении машинки с Дебианом ко всемирной сети посредством
> «мобильника», связанного по блютузу.
> 
> Так вот по-моему это просто плохая идея: блютуз — довольно мерзкий
> способ связи: медленный, короткобойный и склонен к разрывам.

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

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

Дальше все зависит от того, какие именно bluetooth profiles
поддерживает "старый мобильник". Если он умеет pan, то все вообще
здорово кроме скорости, будет этакий новый сетевой интерфейс. 

Если dun, то надо pppd запускать. Впрочем, возможно нынешниее
нетворк-менеджеры это сами умеют.

> По какой причине нет возможности либо:
> а. Выделить для этой цели отдельную сим-карту, каковую вставить в
> модем в ПК (или даже в «роутере»).  Либо же: б. Подыскать
> «мобильник», могущий пускать в Интернет соседей по вай-фаю.

А может у человека как раз в этом и проблема - чтобы он сам в интернет
ходить мог, а "соседи" -нет. Тогда, правда, блютуз ничем не лучше wifi.
С секьюрностью у него даже похуже будет.

> Учитывая, что это _не_ обязательно подразумевает его работу в режиме
> точки доступа, то это почти любая машинка, где вай-фай-радио вообще
> есть.

-- 
   Victor Wagner <vi...@wagner.pp.ru>

Re: андроидный телефон

2018-05-20 Пенетрантность Victor Wagner

В Sun, 20 May 2018 07:58:15 +0300
Dmitry Alexandrov <321...@gmail.com> пишет:

> Victor Wagner <vi...@wagner.pp.ru> wrote:
> >> >> Посоветуйте, пожалуйста, программу для общения с
> >> >> андроидом. ...телефоны нонче в нашей семье не поддерживают
> >> >> представление себя как usb-storage. Разрешают только MTP, PTP и
> >> >> какую-то другую хрень.
> >> >
> >> > 1. Поставить на телефон Total Commander с Lan Plugin-ом
> >> 
> >> Он несвободный, если что.  
> >
> > Так я ж его и не на [основной] компьютер предлагаю ставить. А
> > телефон уже в рабстве у гугла  
> 
> Какого вы, однако, плохого мнения о даме. :-)

После этого письма я буду плохого мнения о вас. Ибо сказано:

"Нет рабства безнадежнее
Чем рабство тех рабов
Себя кто полагает
Свободным от оков".


-- 
   Victor Wagner <vi...@wagner.pp.ru>

Re: андроидный телефон

2018-05-19 Пенетрантность Victor Wagner

В Sun, 20 May 2018 01:18:41 +0300
Dmitry Alexandrov <321...@gmail.com> пишет:

> Victor Wagner <vi...@wagner.pp.ru> wrote:
> >> Посоветуйте, пожалуйста, программу для общения с
> >> андроидом. ...телефоны нонче в нашей семье не поддерживают
> >> представление себя как usb-storage. Разрешают только MTP, PTP и
> >> какую-то другую хрень.  
> >
> > 1. Поставить на телефон Total Commander с Lan Plugin-ом  
> 
> Он несвободный, если что.

Так я ж его и  не на компьютер предлагаю ставить. А телефон уже в
рабстве у гугла - несвободной софтиной больше, несвободной софтиной
меньше.



-- 
   Victor Wagner <vi...@wagner.pp.ru>

Re: андроидный телефон

2018-05-19 Пенетрантность Victor Wagner

В Sat, 19 May 2018 21:19:18 +0300
Vladimir Zhbanov <vzhba...@gmail.com> пишет:

> Посоветуйте, пожалуйста, программу для общения с андроидом. Я сам,
> лично, с ними особо не общаюсь, но вот жене понадобилось что-то
> скачать, а телефоны нонче в нашей семье не поддерживают
> представление себя как usb-storage. Разрешают только MTP, PTP и
> какую-то другую хрень. В своё время использовал какую-то гномскую
> графическую морду для фотика, но жутко неудобную. Что нынеча в
> тренде для этого дела?
> 

Не люблю мод и трендов, но лично сам имею два предпочтительных варианта
1. Поставить на телефон Total Commander с Lan Plugin-ом  (или Ghost
commander с SMB плагином) а на компьютер Samba и копировать по самбе с
телефона.
2. Поставить на телефон какой-нибудь  sshd (сейчас хвалят Termux, но
это скорее не для жены, а для вас), и копировать scp.
Ну и третий, менее предпочтительный:
3. использовать adb (android debugging bridge) в дистрибутиве есть.

В общем не стоит пытаться решить задачу только на компьютере. Надо
навстречу идти с обоих концов.



-- 
       Victor Wagner <vi...@wagner.pp.ru>

Re: LDAP

2018-04-19 Пенетрантность Victor Wagner

On Thu, 19 Apr 2018 08:49:11 +0300
Artem Chuprina  wrote:

>  > учетом современных реалий. Чтобы и X509v3 умело, и эллиптические
>  > кривые понимало, причем не только в виде ECDSA.  
> 
>  > А Шаплова заставим новый Certificates HOWTO написать.  
> 
> Палка о двух концах. В easy_rsa ключевое слово - easy. Мы сумеем
> добавить туда новые возможности, не потеряв в простоте применения для
> простых случаев?

Ну, не попробуем - не узнаем. В общем-то challenge в том и состоит,
чтобы простые вещи были простыми, а сложные - возможными.

> И кстати, оглядываясь на смартфоны и планшеты - у них ведь снова чаще
> чем у каждого второго асимметричный алгоритм "может быть любым, если
> это RSA". И генерировать сертификат на эллиптических кривых -
> нарываться на то, что смартфонное приложение этого не поймет.

По-моему, ты немножко не прав, и в JAVA cryptoapi которому андроид
более-менее следует, все это поддерживается. 

Оно  в сим-картах и то поддерживается. (JavaCard 3.0, если не
ошибаюсь).

А уж в OpenVPN, в которой вообще может быть openssl внизу, даже и в
андроидных сборках...

Вот DSA, который над полем вычетов - это да, все поддерживать перестали.

Но в принципе, задача выбора алгоритма  ключевой пары, отличного от
RSA, может быть отнесена к категории "сложных вещей, которые должны
быть возможны". А по умолчанию делать все с RSA.

--

Re: LDAP

2018-04-18 Пенетрантность Victor Wagner

В Wed, 18 Apr 2018 23:09:45 +0300
Artem Chuprina <r...@lasgalen.net> пишет:

> artiom -> debian-russian@lists.debian.org  @ Wed, 18 Apr 2018
> 22:46:27 +0300:
> 
>  > Собственный CA имеет смысл, вроде.
>  > Вопрос только в том, насколько сложно (LDAP тоже казался простым,
>  > но свои особенности у каждого сервиса сожрали уйму времени)?  
> 
> В свое время в сети гуглился документ SSL Certificates Howto. Там было
> довольно грамотно расписано.

Устарело оно лет на двадцать. Осталось на уровне X509v1.
 
> Сейчас в дистрибутиве есть пакет easy-rsa, им любит OpenVPN
> пользоваться.  Это сделанный по тому рецепту комплект скриптов для
> своего CA.

Вот у нас тоже им пользовались. Коропоративная локалка, примерно 30
пользователей. VPN, LDAP, десяток-другой внутренних веб-сервисов.

Возникла необходимость поднять парочку Name-based https-хостов на одной
машина и ап.. А где SubjectAlternativeName? А не умеет его easy_rsa.
Вообще никаких extension не умеет.
 
> Чтобы им адекватно пользоваться, крайне желательно уже иметь понимание
> устройства PKI по схеме X509 (в PGP, например, схема другая). В
> упомянутом Howto изложение, помнится, было.

Ага было. На уровне  RFC 2459, принятого в прошлом веке.
А сейчас немножко даже 3280 уже неактуально. Надо пользоваться 5280 и
то с оглядкой на 6818.

Может это, тряхнем стариной, да и напишем ремейк easy_rsa, но с учетом
современных реалий. Чтобы и X509v3 умело, и эллиптические кривые
понимало, причем не только в виде ECDSA.

А Шаплова заставим новый Certificates HOWTO написать.
-- 
   Victor Wagner <vi...@wagner.pp.ru>

Re: Почтовый клиент

On Thu, 29 Mar 2018 07:30:20 -0500
"D. H."  wrote:


> 
> > соответственно, входящую почту приходилось пробрасывать через VPN с
> > виртуалки на хостинге. (VPN тут в принципе не обязательна,
> > достаточно настроить транспорт через smtps по нестандартному порту,
> > но если она все равно есть, через нее - проще).  
> 
> А вот тут можно чуть подробнее в случае exim? С ходу как-то не
> нашлось у меня ответа на этот вопрос. Сейчас тоже через vpn пускаю,
> но если есть возможность от него отказаться

Увы, с exim ничем не могу помочь. Потому что обычно использую postfix.

--

Re: Почтовый клиент

On Thu, 29 Mar 2018 12:19:31 +0300
Иван Лох <l...@1917.com> wrote:

> On Thu, Mar 29, 2018 at 12:11:22PM +0300, Victor Wagner wrote:
> >   
> > > > Ходить по imap это правильно. Почта должна лежать в  одном
> > > > месте, и это место должно быть доступно по imap.
> > > 
> > > Это может быть и правильно, но не всегда удобно. На слабых каналах
> > > связи очень тяжко бывает, а если за границей, а если ещё и
> > > дорого...  
> 
> Хм. В моем представлении дорого скачивать письма не читая заголовки 
> (и не глядя на их размер). А список писем+ тот же mutt прекрасно
> кэширует.

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

Вообще было бы интересно сравнить объем траффика, который тратится при
работе с почтой разными способами:

1. "Скачать все" pop3/imap+fetchmail
2. нормальный imap-клиент (тот же mutt, хотя интересно еще и на
графические клиенты посмотреть)
3. web-интерфейс с минимумом client-side динамики (например prayer)
4. хипстерский вебдванольный интерфейс вроде gmail  (наверняка же есть
opensource аналоги)

Re: Почтовый клиент

On Thu, 29 Mar 2018 12:04:44 +0300
Евгений Кабанов  wrote:

> > Ходить по imap это правильно. Почта должна лежать в  одном месте, и
> > это место должно быть доступно по imap.  
> 
> Это может быть и правильно, но не всегда удобно. На слабых каналах
> связи очень тяжко бывает, а если за границей, а если ещё и дорого...

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

Опять же, если это место доступно ЕЩЕ И через веб-интерфейс от этого
никому плохо не будет. Хотя лично я держу веб-интерфейс в основном ради
того маловероятного случая, когда потребуется работать с почтой с чужой
машины. 

Защититься от ненамеренного оставления пароля в (знакомом) браузере все
же проще, чем защититься от того же в незнакомом почтовом клиенте.

--

Re: Почтовый клиент

On Thu, 29 Mar 2018 11:34:34 +0300
Grigory Fateyev  wrote:

> Добрый день!
> 
> Суть проблемы, не могу понять как работать с почтой, когда девайсов
> больше одного!
> 
> Когда был один PC, всё было просто, связка: procmail, fetchmail, exim
> и claws-mail устраивала. Почта по таймеру качалась в директорию
> ~/Mail, procmail всё раскладывал по нужным дирам, было удобно. Сейчас
> девайсов много и возникает вопрос как добиться удобства?

Да, кстати, если почта лежит на imap, то имеет смысл вместо procmail
испоьзовать sieve. Поскольку им удобнее управлять удаленно, используя
протокол managesieve. Для claws-mail существует плагин, позволяющий по
этому протоколу работать.

Re: Почтовый клиент

On Thu, 29 Mar 2018 11:34:34 +0300
Grigory Fateyev  wrote:

> Добрый день!
> 
> Суть проблемы, не могу понять как работать с почтой, когда девайсов
> больше одного!
> 
> Когда был один PC, всё было просто, связка: procmail, fetchmail, exim
> и claws-mail устраивала. Почта по таймеру качалась в директорию
> ~/Mail, procmail всё раскладывал по нужным дирам, было удобно. Сейчас
> девайсов много и возникает вопрос как добиться удобства?
> 
> Хочу: синхронизацию (в идеале хранить в одном месте), доступ и из
> Debian и Android, интерфейс с возможность bottom-quoting и тому
> подобное сейчас в gmail это дико бесит.
> 
> Думаю почту надо хранить на gmail, ходить по imap. Пока рассматриваю
> варианты с gnus (emacs) и claws-mail. Может кто подскажет кто как
> решает эту проблему?

Ходить по imap это правильно. Почта должна лежать в  одном месте, и это
место должно быть доступно по imap. Опционально - вебмейл какой-нибудь.

Но вот это место должно быть ПЕРСОНАЛЬНО вашим. Оптимально - под вашим
физическом контролем. Доверять свою почту гуглю не стоит. Он ее будет
анализировать своими алгоритмами.

Я одно время использовал в качестве почтового сервера RaspBerry PI R1,
которая по совместительству являлась домашним роутером. И это при том,
что у меня провайдер закрывал соединения на входящий 25 порт, и,
соответственно, входящую почту приходилось пробрасывать через VPN с
виртуалки на хостинге. (VPN тут в принципе не обязательна, достаточно
настроить транспорт через smtps по нестандартному порту, но если она
все равно есть, через нее - проще).

Потом по ряду технических причин вся почтовая система вместе с
архивамми уехала на эту виртуалку, и я ощущаю это как заметное
ослабление своей privacy. Хотя виртуалка на хостинге это все равно
много приватнее, чем пользование публичным почтовым сервисом, что в
свою очередь намного приватнее, чем использвание почтового сервиса,
предоставляемого владельцем поисковой машины.

В общем, где-то поставить комбинацию из dovecot+spamassasin+prayer
webmail - это достаточно просто. При условии что это где-то имеет
постоянный IP-адрес, который можно прописать как mx для своего домена.

--

Re: REUSE сокеты

2018-03-22 Пенетрантность Victor Wagner

On Thu, 22 Mar 2018 11:06:42 +0300
Eugene Berdnikov  wrote:

> On Thu, Mar 22, 2018 at 10:35:09AM +0300, Dmitry E. Oboukhov wrote:
> > в 4.1x ядрах выпилили ручку про реюз сокетов.  
> 
>  В дистрибутивных ядрах 4.12, 4.13 и 4.15 для i686 и x86_64
>  ручка net.ipv4.tcp_tw_reuse на месте. Не работает, что ли?

В том коммите, которым из mainline kernel эту ручку выкинули,

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4396e46187ca5070219b81773c4e65088dac50cc

Написано, что выкинули именно потому что не работало, и работать не
могло. Так что если мейнтейнеры в дистрибутиве вкрутили ее обратно, это
никому не поможет.

--

Re: REUSE сокеты

2018-03-22 Пенетрантность Victor Wagner

On Thu, 22 Mar 2018 10:35:09 +0300
"Dmitry E. Oboukhov"  wrote:

> Верну от политики взад.
> 
> в 4.1x ядрах выпилили ручку про реюз сокетов.
> сейчас поставили тестовый сервак: apache/nginx.
> запросов относительно много (где-то 50 в сек), но все короткие.
> 
> система захлёбывается от числа сокетов TIME_WAIT.
> 
> откатили ядро до 4.9 (4.13 ставили из за чего-то с контейнерами, точно
> не знаю).
> 
> 
> смотрел TIME_WAIT'ов много в т.ч. на сокетах apache <-> nginx.
> 
> Думал перевесить чтоли apache на unix-сокет, но так и не дали покопать
> ("нам пилу точить некогда, пилить нужно!")
> 
> 
> вопрос: а как предлагается организовывать сервера на новых ядрах?

Вот здесь:

https://vincent.bernat.im/en/blog/2014-tcp-time-wait-state-linux

пишут, что умолчательных настроек должно хватать на 500 запросов в
секунду. (в распоряжении nginx имеется 3 портов, с которых он может
открыть соединение, а TIME_WAIT по умолчанию 1 минута).

По этой же ссылке дается ряд советов, что делать если все-таки сокетов
не хватает.

Может какие из них и подойдут.

--

Raspberry PI 3 и архитектура aarch64

2018-03-19 Пенетрантность Victor Wagner


Коллеги,

А кто-нибудь тут пытался поднять на Raspberry Pi 3 B64-битный Debian?
Cудя по описанию на сайте, там процессор 64-битный, но образ Raspbian 
дают 32-битный.

Нашел вот такое https://github.com/bamarni/pi64
но оно с прошлого лета не обновлялось. Поэтому прежде чем начинать
экспериментировать, хотелось бы услышать мнение тех, кто уже прошелся
по этой дорожке.

-- 
   Victor Wagner <vi...@wagner.pp.ru>

Re: Проблема с правами доступа в Debian

2018-03-19 Пенетрантность Victor Wagner

On Mon, 19 Mar 2018 16:35:03 +0500
Stanislav Vlasov <stanislav@gmail.com> wrote:

> 19 марта 2018 г., 15:44 пользователь Victor Wagner
> <vi...@wagner.pp.ru> написал:
> 
> >> Потому что подключение диска от другой системы - нештатная
> >> ситуация. Если хотите, чтоб при подобном не было доступа к чужим
> >> данным - шифруйте. А для локального /home - достаточно проверять
> >> uid. Тем более, в файловой системе нет такого атрибута, как имя
> >> пользователя.  
> >
> > Времена изменились. Теперь появились съемные носители с терабайтными
> > емкостями, на которых хочется иметь нормальную файловую систему.
> > Потому что поделия вроде FAT не умеют нормально работаь с такими
> > объемами.  
> 
> Угу. А фс - не изменились. Даже в ntfs нет атрибута "имя
> пользователя", если правильно помню.

В NTFS есть SID.

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

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

Re: Проблема с правами доступа в Debian

2018-03-19 Пенетрантность Victor Wagner

On Mon, 19 Mar 2018 14:31:14 +0500
Stanislav Vlasov  wrote:

> 
> Потому что подключение диска от другой системы - нештатная ситуация.
> Если хотите, чтоб при подобном не было доступа к чужим данным -
> шифруйте. А для локального /home - достаточно проверять uid.
> Тем более, в файловой системе нет такого атрибута, как имя
> пользователя.

Времена изменились. Теперь появились съемные носители с терабайтными
емкостями, на которых хочется иметь нормальную файловую систему.
Потому что поделия вроде FAT не умеют нормально работаь с такими
объемами.

В свое время, когда появились CD-ROM, разработчики RockRidge
extensions к стандарту iso9660 подумали над этим вопросом. Результат
их размышлления имеется в виде ключика -r у wodim - всем файлам
принудительно обнуляется UID и GID, и проставляются права 444 (а
каталогам 555). Потому что на съемном носителе, право читать который
имеет кто угодно - это единственная осмысленная система прав.

Примерно то же самое у нас сделано путем задания опций монтирования
для дисков с FAT. Но вот не тянет FAT нынешних сменных дисков, надо
ext4 или NTFS. А для них никто этот use case не продумывал.
--

Re: Краткий обзор систем резервного копирования

2018-03-15 Пенетрантность Victor Wagner

On Wed, 14 Mar 2018 20:51:12 +0300
artiom  wrote:

> Я думаю, мой "парк" не разрастётся более десятка машин.
> Но я хочу иметь удобный web-интерфейс и единую точку контроля.
> Иначе, зачем я собираю устройство, второй основной задачей которого
> является бэкап?
> 

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

Re: internet radio pleer

2018-03-14 Пенетрантность Victor Wagner

On Wed, 14 Mar 2018 08:36:09 -0500
"D. H."  wrote:

> >   
> а зачем пульсаудио? неужели ещё есть надежда что оно когданибудь
> нормально рабоать будет?

Нет надежды, что кое-какой софт будет работать без него. А так - хоть
как-то.

Re: Краткий обзор систем резервного копирования

2018-03-12 Пенетрантность Victor Wagner

On Mon, 12 Mar 2018 13:56:31 +0500
Stanislav Vlasov  wrote:

> 9 марта 2018 г., 20:36 пользователь Artem Chuprina 
> написал:
> 
> > Для себя сделал вывод, что надежнее самопальной конструкции на базе
> > rsync все-таки ничего не придумали.  
> 
> > Хотя, конечно, дедупликацию к ней добавить было бы приятно... Но
> > надежность и простота восстановления в любом случае важнее.  
> 
> Рекомендую глянуть на rsnapshot - как раз конструкция на базе rsync,

Лет десять назад именно Артем Чуприна научил меня пользоваться
rsnapshot. Поэтому полагаю, что под дедупликацией он имеет в виду
что-то другое, чего rsnapshot не умеет.

--

Re: dnsmasq

2018-03-10 Пенетрантность Victor Wagner

В Sat, 10 Mar 2018 16:59:18 +0300
"Andrey Jr. Melnikov" <temnota...@gmail.com> пишет:


> > и он поэтому намеренно слабенький. На пассивном охлаждении.  
> Вот у меня один из домашних роутеров - Banana Pi R1, при всех его
> конструктивных ляпах - вполне себе роутер. Даже с SSDшкой для всякого

Вот не показалось оно мне "вполне себе роутером" для домашних нужд.
Почему-то там wi-fi точка доступа оказалась с таким слабым сигналом,
что хрен его услышишь по всей квартире (учитывая количество соседских 
вайфаев). Или существует какой-то секретный способ добиться от ее Wi-Fi
модуля правды?

А подобное устройство интересно именно как решение вида "все в одном".
Чтобы одна железяка с максимум 15Вт энергопотребления была и роутером,
и свитчом, и точкой доступа Wi-Fi, и торрентокачалкой и хранилищем тех
немногочисленных файлов, которые должны быть доступны даже тогда, когда
любой другой компьютер в доме выключен.


> хлама. До этого там стоял ящик на атоме. Выкинут под стол из-за
> посыпавшегося диска.
> Купил бы BPi-R2 - но так в нем по хипстерски нет отдельной SPI флшки
> для загрузчика. А хваленые eMMC от хорошей грозы любят покрываться
> нечитабельными блоками.

Так там вроде Wi-Fi вообще нет. Правда PCI-E есть.
 



-- 
   Victor Wagner <vi...@wagner.pp.ru>

Re: dnsmasq

2018-03-09 Пенетрантность Victor Wagner

В Fri, 09 Mar 2018 18:50:22 +0300
Artem Chuprina <r...@lasgalen.net> пишет:

> Хочу поделиться.
> 
> 
> Судя по документации, dnsmasq теперь можно обучить практически всем
> типам записей, т.е. чуть ли не сделать из него полноценный DNS-сервер,
> торчащий наружу. Хотя он вообще-то придуман не для этого.

Ну мы его примерно так используем, только не совсем наружу. а для
всяких внутриофисных доменов, состоящих их виртуальных машин.

> Единственное — не помню, можно ли ему объяснить, что наружу можно
> отдавать запросы по своей зоне, но нельзя делать рекурсивные. Скорее
> всего, можно, потому что про соответствующую атаку авторы в курсе.
> Просто не помню (пока было не надо).
> 
> Чего он явно не умеет (в документации нет даже упоминания), так это
> трансфера зон.

Как нет упоминания?

--auth-sec-servers=[,[,...]]
  Specify  any  secondary  servers for a zone for which dnsmasq is
  authoritative. These servers must be configured to get zone data
  from  dnsmasq  by zone transfer, and answer queries for the same
  authoritative zones as dnsmasq.


   --auth-peer=[,[,...]]
  Specify the addresses of secondary servers which are allowed  to
  initiate  zone transfer (AXFR) requests for zones for which dns‐
  masq is authoritative. If this option is not  given,  then  AXFR
  requests will be accepted from any secondary.



То есть ОТДАВАТЬ зону посредством zone transfer он умеет и еще как.


-- 
   Victor Wagner <vi...@wagner.pp.ru>

Re: Как подключиться к X-серверу по локальной сети?

2018-03-04 Пенетрантность Victor Wagner

В Sun, 4 Mar 2018 13:50:39 -0500
Tim Sattarov <sti...@gmail.com> пишет:

> On 03/04/18 11:50, Maxim Nikulin wrote:
> > 04.03.2018 04:12, Tim Sattarov пишет:  
> >>
> >>   * разрешить удалённые подключения к X серверу
> >>     |xhost +| на X-сервере (rpi)  
> >
> > И получить себе на дисплей от другого пользователя какой-нибудь
> > xspy.
> >
> > Ssh пробрасывает DISPLAY аккуратнее.
> >  
> речь была про производительность, а не безопасность
> по SSH она будет хуже

Можно еще man xauth почитать и сделать как следует.




-- 
   Victor Wagner <vi...@wagner.pp.ru>

Re: Java https сервер на умолчательном порту

2018-03-03 Пенетрантность Victor Wagner

В Sat, 3 Mar 2018 23:39:09 +0500
Коротаев Руслан <subscr...@mail.kr.pp.ru> пишет:

> В сообщении от [Сб 2018-03-03 19:21 +0300]
> Victor Wagner <vi...@wagner.pp.ru> пишет:
> 
> > А вот интересно, если в пакете unit-файла нет, есть только
> > init.d-скрипт, но системой инциализации работает systemd, эти файлы
> > будут обрабатываться?  
> 
> Да, будут обрабатыватся в режиме совместимости, выглядит он также как
> юнит, например exim4.service. В таком режиме есть нюансы, о них можно
> подробно почитать в этой книге [1] на русском (главы «Преобразование
> SysV init-скрипта в systemd service-файл» и «Совместимость с SysV»).
> Также много литературы на импортном вот здесь [2].
> 
> Если коротко, то вместо init-скрипта, например foobar, создаете файл с
> таким же именем в /etc/systemd/system/foobar.service и будет
> запускаться он, а не init-скрипт.

Если я правильно понимаю, то не вместе с init-скриптом, а вместо него,
что отличается от ситуации когда в пакете сервис-файл есть, и тогда
пользовательские файлы из /etc/systemd читаются вместе с системным
(пакетным) файлом .service и пользовательские настройки по определенному
алгоритму комбинируются с системными.





> 
> [1]: http://www2.kangran.su/~nnz/pub/s4a/s4a_latest.pdf
> [2]: https://www.freedesktop.org/wiki/Software/systemd/
> 



-- 
   Victor Wagner <vi...@wagner.pp.ru>

Re: Java https сервер на умолчательном порту

2018-03-03 Пенетрантность Victor Wagner

В Fri, 2 Mar 2018 18:10:13 +0300
Alex Kicelew <arko...@gmail.com> пишет:

> On 03/02/18 18:03, Victor Wagner wrote:
> >> Если не возражаете против использования systemd для запуска
> >> программы, то добавьте в юнит такую строчку:  
> > Вот это - однозначно вредный совет. Только сегодня напоролся
> > (правда, совсем с другой программой).  
> 
> Эти строки можно добавить в
> /etc/systemd/system.control/имя-сервиса.service.d/произвольное-имя.conf.
> Эти файлы не трогаются пакетным менеджером и всегда используются при
> старте имя-сервиса.service.

А вот интересно, если в пакете unit-файла нет, есть только
init.d-скрипт, но системой инциализации работает systemd, эти файлы
будут обрабатываться?



-- 
   Victor Wagner <vi...@wagner.pp.ru>

Re: Java https сервер на умолчательном порту

2018-03-02 Пенетрантность Victor Wagner

On Fri, 2 Mar 2018 17:58:56 +0500
Коротаев Руслан  wrote:

> 
> Если не возражаете против использования systemd для запуска программы,
> то добавьте в юнит такую строчку:
> 
> [Service]
> …
> ExecStartPre=/sbin/setcap
> cap_net_bind_service=+ep /usr/local/bin/myprog …

Вот это - однозначно вредный совет. Только сегодня напоролся (правда,
совсем с другой программой).

Дело в том, что unit-файл systemd, в отличие от скриптов в /etc/init.d
не рассматривается дебиановской пакетной системой как конфигурационный
файл, пользовательские изменения в котором надо тщательно сохранять при
апгрейде софтины. Поэтому как только из репозитория приедет новая
версия пакета, добавленная вручную в unit строчка ExecStartPre (или
Environment) оттуда испарится.

С другой стороны авторы пакетов jenkins - люди консервативные.
И у них в пакете нет unit-файла, и systemd его запускает через
init.d-шный скрипт. Который вообще-то конфигом считается.

Правда не факт, что  в следующей версии пакета у них unit не появится.

Java https сервер на умолчательном порту

2018-03-02 Пенетрантность Victor Wagner

Коллеги,

Вот есть такая проблема: Имеется java-приложение (jenkins) которое
умеет работать веб-сервером, в том числе и по https.

Ставится оно из deb-пакета, предоставляемого производителем приложения
и работает от своего собственного непривилегированного юзера.

В пакете есть файлик в /etc/defaults через который можно много что
настроить, в частности порты на которых слушает web-сервер.

Проблема в том. что хочется чтобы оно слушало на дефолтном порту для
https, т.е. 443.

Для того, чтобы java-приложению дали прибиндиться к порту < 1024, надо
сделать

sudo setcap CAP_NET_BIND_SERVICE=+eip /usr/bin/java

Мне, в принципе не жалко, большой дыры в безопасности мне это не
создаст (тем более что машинка в интранете). Проблема в другом.
Через пару месяцев другой сотрудник, которому либо я забыл рассказать
про setcap, либо я рассказал, да он забыл, сделает на этой машинке
apt-get upgrade, и к нему приедет апгрейд OpenJDK. И при изменении
бинарника capabilities слетят. И jenkins перестанет запускаться.

Вопрос в том, а куда бы наиболее соответствующим политике дистрибутива
способом прописать скрипт, который будет делать этот вызов setcap,
чтобы быть уверенным что в момент запуска jenkins бинарник java будет
иметь требуемые capabilities?

Понятно, что пересобирать самому пакеты ни jenkins, ни, упаси боже,
openJDK, не хочется.

(кстати из man setcap я не понял что произойдет с capabilities при
простой перезагрузке, без изменения бинарника - сбросятся они или нет?
Вроде у нас persistent state в linux не принят).

Re: научите systemd!

2018-02-26 Пенетрантность Victor Wagner

В Mon, 26 Feb 2018 15:20:32 +0300
Artem Chuprina <r...@lasgalen.net> пишет:


> Чтоб два раза не вставать: я понимаю, почему юзерский юнит не может
> прописать зависимость от системного. (В документации, кстати, я этого
> не нашел, но гуглится.) Но я уже перестаю понимать, почему автор такой
> архитектуры до сих пор не поскользнулся на арбузной корке...
> 
'
Потому что юзеры, порченные мукой и чародейством Билла Гейтса и Стива
Джобса, обожают терпеть мелкие неудобства.

И вообще человек много что готов вытерпеть ради того, чтобы не думать,
не понимать и не брать на себя ответственность.


-- 
       Victor Wagner <vi...@wagner.pp.ru>

Re: научите systemd!

2018-02-25 Пенетрантность Victor Wagner

On Mon, 26 Feb 2018 03:38:06 +0300
sergio  wrote:

> On 25/02/18 08:59, sergio wrote:
> 
> > А как включить его обратно?  
> 
> Обратно, конечно, так:
> 
> # apt remove xdm && apt install xdm

Может все-таки install надо было что-то другое?
lightdm к примеру? Или gdm?

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

Re: Минималистичный инструмент для организации хранения структуры данных "многие ко многим"

2018-02-22 Пенетрантность Victor Wagner

On Thu, 22 Feb 2018 11:03:22 +0300
Artem Chuprina  wrote:


> 
> Если говорить о tab separated и однострочниках, то однозначный выбор
> языка - perl.
А еще у perl DBD::CSV есть.

Re: Минималистичный инструмент для организации хранения структуры данных "многие ко многим"

2018-02-21 Пенетрантность Victor Wagner

В Wed, 21 Feb 2018 18:45:12 +0700
Denis <notabenaaba...@gmail.com> пишет:

> Привет!
> 
> Предложите инструмент по сабжу. Решается задача для fun'a, поэтому не 
> стесняйтесь (общение в рамках решения этой задачи является частью
> fun'а)

Используйте обычные coreutils. Их возможности (если вместе с awk)
вполне достаточны для решения поставленной задачи.
Храните данные в формате Tab separated  по одной таблице в файле и
впред.

Если же хочется использовать sql, то рекомендую sqlite. У него формат,
конечно, не текстовый, но зато оно нет требует никаких постоянно
работающих процессов, как рекомендованный в соседнем письме mysql.

Ну и скрипты лучше писать не на баше, а на питоне. Благо у него
поддержка sqlite в стандартной библиотеке.

Я вообще считаю, что писать "на баше" не следует никогда. Если ты
пишешь шелловский скрипт, он должен быть совместимым со
стандартным /bin/sh. Повторяю - не с ash, который у нас обычно заменяет
/bin/sh, не с фрибсдшным /bin/sh (хотя и с ними тоже), а с настоящим
юниксовым Bourne Shell (из ближайшего соляриса). 

Если же возможностей bourne shell не хватает, стоит сразу
переориентироваться на perl, python, ruby или lua.



-- 
       Victor Wagner <vi...@wagner.pp.ru>

Re: Backup

2018-02-20 Пенетрантность Victor Wagner

В Tue, 20 Feb 2018 20:56:03 +0300
artiom <artio...@yandex.ru> пишет:

ю, сбой диска убьет
> > единственный. 
> Возможно, при ограниченных ресурсах по аппаратуре это применимо, но в
> целом, я считаю, подход неправильный.
> Надёжность хранилища должна нижним уровнем обеспечиваться.
> Явно не прикладным, на котором работает система резервного
> копирования.

Нет, именно на прикладном - единственный способ обеспечить надежность
за разумные деньги.

Тем более, что на прикладном уровне мы можем защищаться от таких угроз
как "разряд высокого напряжения попал в розетки и убил всю включенную
электронику в здании" (путем хранения бэкапа на физически отключенном
устройстве) и даже от угроз "пожар" и "падение атомной бомбы на город"
(путем хранения одной из копий в географически удаленной локации)

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



-- 
   Victor Wagner <vi...@wagner.pp.ru>

Re: Backup

2018-02-19 Пенетрантность Victor Wagner

On Sun, 18 Feb 2018 23:34:56 +0300
Artem Chuprina  wrote:

>  > В общем-то я это и хотел услышать. Есть "учебная" машина. Работа
>  > основной инфраструктуры ради проверки восстановления не
>  > прерывается.  
> 
> Вообще говоря, возможны ситуации, когда приходится прерывать. Потому
> что оценить результат восстановления можно только протестировав, что
> все документированные функции целевой машины работают. А у нее могут
> быть сетевые сервисы, которые надо проверить по тому самому имени.
> Для чего "учебная" машина должна подменить в сети "боевую".

А я вот подумал - а не дешевле ли будет подсунуть учебной
восстанавливаемой машине учебный интернет с учебными DNS-ами и учебным
mx-ом? Ну и парочкой учебных рабочих станций, куда админ после
восстановления может зайти и обратиться ко всем сервисам, которые надо.

Понятно, что это тоже излишние трудозатраты на учебную тревогу. Зато
результаты работы проверяются корректно, а учебная сеть делается один
раз на все бэкапимые машины.

--

Re: Backup

2018-02-15 Пенетрантность Victor Wagner

В Thu, 15 Feb 2018 22:59:07 +0300
artiom <artio...@yandex.ru> пишет:

> Подскажите, чем возможно выполнять резервное копирование нескольких
> машин по сети, чтобы условия ниже были удовлетворены.
> 
> Склоняюсь к следующим вариантам:
> 
> - Bacula.
> - BackupPC.
> - Решения на базе rsync.
> 
> Изо всего работал только с rsync, о Bacula имею представление, а
> BackupPC мне неизвестен.
> 
> Резервное копирование хочу выполнять на центральное хранилище, с
> FreeNAS. Основные машины - PC с Debian и ноут с Debian.
> Ноут преимущественно подключен через Интернет, PC в локальной сети.

Я использую надстройку над rsync, называющуюся rsnapshot.
Бэкаплю таким образом и домашнюю машину на USB-диск и виртуалку на
хостинге на домашную машину (по расписанию)

> Также, в перспективе, могут резервироваться машины с Windows и MacOS,
> возможно Android планшет.

Вот windows rsync-ом не забэкапишь. Windows я в свое время бэкапил
ntfsclone способом "перегрузился в linux, создал клон". Но это для
ситуации когда пользовательские данные в ней не хранятся. 

> На Debian-based машинах хочу резервировать конфигурацию в /etc и
> выбранные пользовательские данные.

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

В общем, анализировать бэкапные решения надо начинать не с "где
хранить" и "какой транспорт использовать" а с "как будет выглядеть
процедура восстановления". Причем в двух вариантах 

1. Сдох жесткий диск, вставляем новый
2. Обнаружилось, что мы случайно стерли/испортили чрезвычайно ценный
файл, который еще в прошлую субботу точно был.

Вот по части второго решения на базе rsync вне конкуренции.

> 
> Резервное копирование хотелось бы выполнять:
> - По расписанию.
> - По запросу.
> - При пропуске предыдущего.
> 
> Условия:
> 
> - Все каналы должны быть зашифрованы.
> - Копирование не должно занимать много времени (используется
> Интернет).
> - Должна быть потенциальная возможность репликации в облако (куда,
> пока не знаю, потому должна быть возможность гибко настроить) с
> шифрованием бэкапов.

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

Опять же шифрованные бэкапы в облаке обычно не слишком удобны для
второго из вышеописанных сценариев:

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

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

в


-- 
   Victor Wagner <vi...@wagner.pp.ru>

Re: Странная проблема

2018-02-12 Пенетрантность Victor Wagner

В Tue, 13 Feb 2018 05:37:55 +0300
Dmitry Alexandrov <321...@gmail.com> пишет:

> > а) не переключаться в системную консоль. Единственное зачем мне это
> > бывает нужно делать, это если какая-нибудь графическая программа
> > (например файрфокс) начинает не просто тормозить, а блокировать весь
> > X-сервер, тогда зайти и прибить.
> 
> А она прямо все Иксы блокирует, или просто захватывает на себя ввод?

А как это определить? В смысле в тот момент, когда X-ы уже не реагируют
ни на клавиатуру, ни на мышь, а из происходящих без воздействия
пользователя вещей на экране от силы пара xterm-ов какую-нибудь
сборку крутят?

Послать самому себе сообщение в телеграм или джаббер?
  
> Во втором случае, вероятно, ее совершенно ни к чему было бы
> прибивать, когда можно просто освободиться от захвата.  Для этого
> даже сочетание клавиш назначено из коробки: , где
>  — это косая черта, которая на цифровой клавиатурке.
> 
> Только сам механизм по-умолчанию отключен, ибо именно на захвате
> ввода работают иксовые блокировщики экрана.  Но его можно временно
> включить, а потом как-нибудь выключить.  Например, таким костылем:

Решение хуже болезни. Потому что подобная фигня с мозилкой случается
раз в месяц, если не реже, а блокировщиком экрана я пользуюсь ежедневно.




-- 
   Victor Wagner <vi...@wagner.pp.ru>

Re: Странная проблема

2018-02-12 Пенетрантность Victor Wagner

On Mon, 12 Feb 2018 16:59:27 +0300
Слученко Владимир Евгеньевич  wrote:

> Приветствую!
> 
> Испытываю странную проблему.
> 
> Я работаю в GUI на Linux Mint.
> 
> При переключении на системную консоль TTY1-n (Ctrl-Alf-F1 )
> отключается видеоадаптер. Монитор сигнализирует "Нет сигнала", А по
> косвенным признакам продолжает работать.
> Переключится обрато в GUI (Ctrl-Alf-F7 ) после этого не получается.
> Чтобы вернутся к работе приходится жёстко выключать компьютер.
> 
> Подскажите пожалуйста, чем может быть вызвано такое поведение и как
> его можно устранить?

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

б) разобраться с альтернативными, нежесткими способами выключения
компьютера
1. Зайти по ssh с любого другого устройства (см выше) и дать команду
shutdown
2. Разобраться почему короткое нажатие  на кнопку питания не приводит к 
штатному отключению компьютера (что должно уж лет десять как
происходить всегда, если никто не игрался с настройками ACPI), и
требуется жесткая перезагрузка.

Re: skypeforlinux

2018-01-31 Пенетрантность Victor Wagner

В Wed, 31 Jan 2018 15:43:04 +0200
Pavel Gaidai <smeeguli...@gmail.com> пишет:

> Всем Привет!
> 
> Нужно вытянуть историю из нового скайпа и отправить на емайл. Если
> кто-то такое делал, подскажите, как?

skype хранит все свои данные в
~/.config/skypeforlinux
Причем в основном в виде баз sqlite.

При этом история общения в конкретном чате забивается в одно поле одной
записи в виде большого-большого json-а.



-- 
       Victor Wagner <vi...@wagner.pp.ru>

Re: переключение языков в иксах

2018-01-14 Пенетрантность Victor Wagner

В Sat, 13 Jan 2018 19:32:28 +0300
Pavel Volkov <sai...@lists.xtsubasa.org> пишет:

> On пятница, 12 января 2018 г. 21:06:07 MSK, Sohin Vyacheslaw wrote:
> > Приветствую,
> >
> > на данный момент у меня переключение языков настроено
> > Caps/Shift+Caps: Option "XkbOptions"
> > "terminate:ctrl_alt_bksp,grp:caps_toggle,grp_led:scroll"
> >
> > Может кто-нибудь из рассылки юзает более удобные сочетания?
> > плз поделитесь...  
> 
> Не совсем в тему, но использую compose key для ввода ряда
> спецсимволов: тире, градус, знак ударения, знак умножения, кавычки,
> евро, копирайт и т. д.
> В качестве compose key — правый Alt.
> Например, правый Alt + d, чтобы поставить градус°.

По-моему, стандартное использование Compose Key куда проще запоминается:
когда последовательно надо нажать

Compose ^ 0 для градуса
Сompose ^ 2 для ² (двойка в верхнем индексе) и т.д.
Compose --- для тире
Compose a e для æ 
Compose o c для ©

То есть использовать слово Compose по смыслу "скомпоновать сложный
символ из нескольких простых".

Это есть во всех стандартных раскладках. 

Я, конечно, понимаю, что если у человека есть потребнность еще и
хатакану с кираганой вводить, там может быть по-другому и использование 
правого Alt как модификатора осмысленно.

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

> Это обеспечивается раскладкой typo.
> 
> Option "XkbLayout" "jp+typo,ru:2+typo"
> Option "XkbOptions" 
> "grp:caps_toggle,grp_led:scroll,terminate:ctrl_alt_bksp,lv3:ralt_switch"
> 

-- 
   Victor Wagner <vi...@wagner.pp.ru>

Re: Как пропатчить wi-fi (wpa-supplicant) в антикварных версиях Debian?

2017-10-30 Пенетрантность Victor Wagner

On Mon, 30 Oct 2017 15:57:47 +0200
Pavel  wrote:

> Доброго всем времени суток. 
> 
> Есть несколько машин с Debian 6 (squeeze) и ранним wheezy (ок. 2013). 
> И тут началась истерия с кряком wi-fi и требуют его залатать. 
> 
> Вопрос: имеет ли смысл бэкпортить патч wpa-supplicant
> http://w1.security/2017-1/ на старинные версии, или уже бэкпортить
> весь wpa-supplicant из свежей версии (допустим, stretch). 
> 
> Реально ли это? Кто нибудь уже пробовал?

По-моему, сбэкпортить весь wpa-supplicant проще. Помнится, было дело я
уже бэкпортил из stretch в jessie (правда по совсем другим причинам -
пытался, безуспешно, добиться нормальной поддержки bananapi в hostapd).

--

Re: выпил systemd и invoke-rc.d

2017-10-28 Пенетрантность Victor Wagner

В Fri, 27 Oct 2017 19:13:13 +0300
Artem Chuprina <r...@lasgalen.net> пишет:

the root
>  > window.  
> 
>  >X_RESOLUTION=num
>  >the x resolution of the screen in pixels per
>  > meter.  
> 
>  >Y_RESOLUTION=num
>  >the y resolution of the screen in pixels per
>  > meter.  
> 
> А теперь призовая игра. Она, кстати, не только для xrdb призовая, и
> более того, может оказаться, что для гнома она окажется на порядок
> более призовой. А может и нет, вопрос в том, в каких единицах оно
> поймет шрифт. Но для xrdb оно точно призовое. Допустим, у нас два, а
> лучше три одновременно подключенных монитора, и по жабно-историческим
> причинам у них X_RESOLUTION и Y_RESOLUTION разные. Было бы клево,
> чтобы размер шрифта был на обоих мониторах одинаковый хотя бы в
> линейных единицах (в идеале, конечно, угловых, но вот данных о
> расстоянии от глаз до монитора у нас точно нет - зато есть неплохие
> шансы, что оно близкое). А вовсе не в пикселах, которые по размеру
> могут отличаться в полтора раза с легкостью.
>
В смысле, проблема в том, что препроцессор C не умеет выполнять
простейшие арифметические операции?
 


-- 
   Victor Wagner <vi...@wagner.pp.ru>

Re: выпил systemd и invoke-rc.d

On Fri, 27 Oct 2017 17:15:51 +0300
Eugene Berdnikov  wrote:

> On Fri, Oct 27, 2017 at 03:48:18PM +0300, Andrey Jr. Melnikov wrote:
> > Да??? git научился фигурно вырезать куски из .Xresources? Или у него
> > появились провидческие знания, что на нетбуке мне нужен фонт
> > размером 10, а на офисной машине - 12?  
> 
>  Вырезать куски умеет препроцессор cpp, через который xrdb пропускает
>  Xresources. Да, провидческие знания придётся завернуть в опции
> командной строки для xrdb, но это можно делать одним для всех машин
> скриптом.

Там значительная часть необходимых знаний о том, что за экран у нас
сегодня, передается xrdb на автомате.

Нижеприведенное - далеко не все, я безжалостно покоцал все, что на мой
взгляд не влияет на шрифты. 

   SERVERHOST=hostname
   the hostname portion of the display to which you are connected.

   CLASS_visualclass_depth=num
   A symbol is defined for each visual supported for  the  screen.
   The  symbol includes the class of the visual and its depth; the
   value is the numeric id of the visual.  (If more than one  vis‐
   ual  has  the same class and depth, the numeric id of the first
   one reported by the server is used.)

   HEIGHT=num
   the height of the root window in pixels.

   WIDTH=num
   the width of the root window in pixels.

   PLANES=num
   the number of bit planes (the depth) of the root window.

   X_RESOLUTION=num
   the x resolution of the screen in pixels per meter.

   Y_RESOLUTION=num
   the y resolution of the screen in pixels per meter.

Re: выпил systemd и invoke-rc.d

On Fri, 27 Oct 2017 15:48:18 +0300
"Andrey Jr. Melnikov"  wrote:

> 
> > настройка такого приложения как терминал выполняется один раз.
> > после этого конфиги распространяются между всеми своими рабочими
> > станциями при помощи например Git.  
> Да??? git научился фигурно вырезать куски из .Xresources? Или у него
> появились провидческие знания, что на нетбуке мне нужен фонт размером
> 10, а на офисной машине - 12?

Вообще-то для фигурного вырезания кусков из .Xresources еще с 80-х
годов прошлого века применяется C-шный препроцессор.
И там вполне можно писать что-то вроде

!if SCREEN_WIDTH > 1024 
*Font: some-big-font
!else
*Font: some-small-font
!endif

Тогда при появлении новой машины с экраном уже известного разрешения
не придется вспоминать где у какого приложения в менюшке смена шрифта.
Просто из .Xresources автоматически вырежется нужный кусок.

--

Re: выпил systemd и invoke-rc.d

On Thu, 26 Oct 2017 15:27:59 +0300
"Andrey Jr. Melnikov"  wrote:

> Dmitry E. Oboukhov  wrote:
> > [-- text/plain, кодировка quoted-printable, кодировка: utf-8, 63
> > строк --]  
> 
> 
> > > У нас опять разные дебианы?  
> >  Тебе ж сказали: без systemd.  
> 
> > >>> А у нас есть GUI которыми можно пользоваться и чтоб без
> > >>> systemd?  
> > >> я чет ваще не понимаю в чем смысл GUI и init общаться? init
> > >> запустил GUI, а дальше-то зачем GUI зависеть на init?  
> > > Он не зависит от init напрямую, он зависит от компонентов init'a
> > > вмоноличенных в systemd.
> > > T.e. для монтирования дисков раньше был udisk2 + polkit,  
> 
> > чет я не вгоняю, каким боком GUI к монтированию дисков.
> > ЗАЧЕМ?  
> Затем, что для монтирования дисков нужны привелегии. А их получить
> можно только спросив у юзеря пароль. Иначе получается дыра в

Не обязательно. Может быть демон, который изначально работает с правами
рута. И реализует любую политику безопасности. Например, смотрит чья
X-сессия на том мониторе, в usb-разъем которого воткнули диск, и
монтирует именно с правами этого пользователя.

Может быть suid-бинарник, который, естественно, в курсе кто его на
самом деле запустил. И все это без GUI.

> безопасности - подключил ты свой диск с веселыми картинками - а сосед
> Вася, который был случайно залогинен на этой машине - картинки то у
> тебя и скопировал.

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

Re: выпил systemd и invoke-rc.d

On Thu, 26 Oct 2017 15:12:20 +0300
"Andrey Jr. Melnikov"  wrote:


> 
> > Или openbox. Тоже вполне минималистичная хрень. Не знаю, правда,
> > насколько там легко оборвать окнам titlebar-ы. Но панель там точно
> > не своя а, например от lxde.  
> Оно конечно хорошо, но это всё надо _настраивать_. Причем, долго

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

В гуглях - не надо, надо в man. Оно документировано.
> тут прописывать. Лет 15 назад у меня было желание писать портянки
> конфигов - сейчас куда-то делось.

А портянку написанную 15 лет назад потерял? Ее слегка подрихтовать под
изменившиеся вкусы, и продолжать использовать.

> Ага, преднастроенная система - это недостаток? Одно дело когда у нас

Да. Я лично предпочитаю держать свои настройки в git или fossil и
переносить с машины на машину. Потому что это система должна под меня
подстраиваться, а не я под нее.

Я еще в 2001 году писал, что хороший интерфейс должен быть не другом
пользователя, а послушным рабом.
--

Re: Вот как бы этому вашему systemd объяснить...

2017-10-25 Пенетрантность Victor Wagner

On Wed, 25 Oct 2017 12:56:29 +0300
Alex Kicelew  wrote:

> > 
> > Вот что надо туда дописать, чтобы systemd понимал, что если процесс
> > vws autostart завершился с нулевым кодом и не оставил ни одного
> > потомка, то так и надо, и сервис active, а ExecStop при покладании
> > системы надо выполнять?
> >   
> 
> Не уверен, что правильно понял задачу (недостаточно подробно описаны
> возможные кейзы), но если понял правильно, то:

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

Далее, в процессе работы загруженной системы могут быть запущены
процессы, которые с точки зрения systemd не имеют отношения к данному
сервису, а с моей - имеют. И команда, запускаемая по ExecStop их
корректно завершит.

Поэтому команда ExecStop должна выполняться независимо от того были ли
ли запущены в результате ExecStart долгоживущие процессы. Но если они
были, то обращаться с ними надо как в случае Type=forking

> 1) чтобы процесс считался запущенным при завершении ExecStart с

В данном случае, наверное, "сервис считался запущенным", а  не
"процесс". То есть с моей точки зрения это выглядит как "сервис
считается запущенным, даже если ни одного рабочего процесса не создано".

> нулевым кодом вне зависимости от того, породились потомки, или нет, и
> при этом не считался запущенным, если ExecStart вышел с ненулевым
> кодом: Type=oneshot
> RemainAfterExit=yes
> 
> 2) если процесс в результате 1) считается запущенным, то ему будет
> выдан ExecStop
>

Вот как бы этому вашему systemd объяснить...

2017-10-25 Пенетрантность Victor Wagner

Коллеги,

есть вот такой service file:

[Unit]
Description=Virtual Workstation Autostart
Documentation=man:vws(1)
After=network.target dnsmasq.service
[Service]
Type=forking
ExecStart=/usr/bin/vws autostart
ExecStop=/usr/bin/vws shutdown --wait
Restart=no
[Install]
WantedBy=multi-user.target
Alias=vws.service


Вот что надо туда дописать, чтобы systemd понимал, что если процесс
vws autostart завершился с нулевым кодом и не оставил ни одного
потомка, то так и надо, и сервис active, а ExecStop при покладании
системы надо выполнять?

Re: выпил systemd и invoke-rc.d

On Tue, 24 Oct 2017 13:12:49 +0300
"Andrey Jr. Melnikov" <temnota...@gmail.com> wrote:

> Victor Wagner <vi...@wagner.pp.ru> wrote:
> > On Mon, 23 Oct 2017 21:46:42 +0300
> > "Andrey Jr. Melnikov" <temnota...@gmail.com> wrote:  
> 
> > > Artem Chuprina <r...@lasgalen.net> wrote:  
> > systemd
> > >   
, которые слишком многого не требуют.  
> 
> Витус, покажи мне _нормальный_ эмулятор терминала для начала? 
> С табами, понимающий авангард utf-8, не падающий от неожиданно

Ну я использую lxterminal. Да, он вообще-то из комплекта lxde, но это
не мешает его использовать отдельно.

> > НУ и какой-нибудь легкий wm, чтобы обеспечивал взаимодействие и не
> > мешал.  
> Для меня - "не мешал" это: 
> - окно не имеет рамок в 100500+ пикселей (для слепых);
> - окно не имеет title bar как такового (чего там пишут обычно нафиг
> не надо, кнопочками - не пользуюсь);
> - WM не рисует прибитый гвоздями task bar с "пуском", сотней кнопочек
> открытых окон и шморгающих когда там что-то происходит.

Тогда для тебя fvwm. Меня заставило с него уйти в свое время именно
неумение правильно работать с utf-8 в titlebar. Ну и taskbar  у него
такой, что я еще в 2002 году свой собсвтенный на tcl/tk взамен писал.

А если titlebar и taskbar не нужны, то бесконечная настраиваемость
fvwm - сплошные плюсы. 

Или openbox. Тоже вполне минималистичная хрень. Не знаю, правда,
насколько там легко оборвать окнам titlebar-ы. Но панель там точно не
своя а, например от lxde.

> > Я, например использую в качестве window manager-а jwm.  
> Очередной эмулятор "с кнопокой пуск" и унылым таскбаром в стиле
> "windows 95" ? Скриншот покажи, когда открыто как минимум 20 окон.

Именно. Тот минимальный набор требований к панели, который у меня
есть, он реализует. 

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

Так это же недостаток. Ну если конечно пользователь умеет читать, а не
только гуглить, и настраивает не по "мутной инструкции из интернета", а
по родной документации. У JWM в этом плане, конечно хреново что конфиг
xml-ный. Но зато хорошо, что он умеет его валидировать без перезапуска
и можно избежать того, что в результате ошибки в конфиге придется
сваливаться в failsafe сессию с одним xterm-ом посреди экрана.

Re: выпил systemd и invoke-rc.d

On Tue, 24 Oct 2017 11:26:40 +0300
Artem Chuprina  wrote:

ере-то гуя и нет.
> 
> У нас вот на сервере без systemd трудно пользоваться zfs. Но ей и с
> systemd пользоваться трудно, как выяснилось.
> 
То есть от systemd никакого толку все равно?

У меня вот единственным оправданием наличия systemd является
необходимость держать в lxc-контейнерах разные линуксы с systemd для
тестирования. Тут уж никуда не денешься - либо держать все в KVM-е, либо
держать systemd на хосте. Второе все же дешевле.

Re: выпил systemd и invoke-rc.d

On Tue, 24 Oct 2017 10:45:12 +0300
"Dmitry E. Oboukhov"  wrote:

> >>> У нас опять разные дебианы?  
> >> Тебе ж сказали: без systemd.  
> 
> > А у нас есть GUI которыми можно пользоваться и чтоб без systemd?  
> 
> я чет ваще не понимаю в чем смысл GUI и init общаться? init запустил
> GUI, а дальше-то зачем GUI зависеть на init?

Ну это такой замысел был у Поттеринга. Создать систему которая
контролирует все. Ну и авторы Desktop Environments  пошли у него на
поводу и стали пользоваться сервисами, предоставляемыми systemd.

> 

> ну Gnome - знатные извращенцы.
> кстати именно из за дебилизма Gnome-майнтенеров и пропихнули эту
> гадость как "основной init": эти криворучки не смогли нормально его
> отпилить и им было дешевле решить вопрос "политически" - протолкнуть
> каку на роль основного init, чем решать вопрос инженерно (отправив
> набор патчей в Gnome)

Это не дебилизм. Это осознанная позиция. Сделать систему возможно
более монолитной и тесно связанной. У этого подхода есть определенные
преимущества (которыми и объясняется популярность Gnome), но цена
по-моему неприемлема.
--

Re: выпил systemd и invoke-rc.d