from:"artiom"


Да это я видел, спасибо.
Там ещё был конфиг, где сетки прописаны всякие, но сейчас я его что-то 
не могу найти.

В общем, переделывать всё-равно придётся...

13.01.2020 08:12, Илья пишет:

В Sun, 12 Jan 2020 22:39:47 +0300
artiom  пишет:


You can change the default machine folder by selecting Preferences from
the File menu in the Oracle VM VirtualBox main window. Then, in the
displayed window, click on the General tab. Alternatively, use
VBoxManage setproperty machinefolder. See Section 8.31, “VBoxManage
setproperty”.




Общие виртуальные машины и настройки Virtualbox у меня хранятся в
отдельном каталоге отдельного пользователя.
Для этого в его домашнем каталоге есть подкаталог с настройками Vbox.

Раньше, чтобы указать путь к настройкам, использовался
`/etc/vbox/vbox.cfg`.

Я давно не запускал VBox, он потребовался, я увидел, что машин нет.
`vbox.cfg` стал obsolete, да я и не помню, что там писать.

Подскажите, как сказать VBox, чтобы настройки он искал в указанном
месте?

Re: Virtualbox

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

Так что, это не по теме ответ.

Но если уж дальше не по теме...

OFFTOPIC:

Касательно QEMU/KVM: я давно не пользовал его.
Для серверов, без сомнения, - штука отличная, предпочтительный вариант.
Для пользовательских ОС, я не знаю.
Просветите, как у него с графикой сейчас?
Насколько хороша поддержка того же Windows?
Т.е., могу я поставить гостевую винду и получить (без извращений, штатно):

- Графическое ускорение (что мне совершенно необходимо).
- Расшаренные каталоги между гостем и хостом.
- Интеграцию с хостовым UI хотя бы на уровне автоматического определения
принадлежности мыши и d

- Проброс оборудования?

Касательно ZFS - не более "поделка", чем ext4 или LVM. Линус
выпендривается, и даже при его замашках, нет серьёзных нареканий к
системе, помимо лицензирования и мифических "бенчмарков".

А я видел другие бенчмарки: по ним всё ok.
ZFS - отличная грамотно продуманная система, и она крайне большую пользу
Linux могла бы принести. А уж реализована она в целом гораздо лучше, чем
пишет код то же сообщество и прочие Линусы.

Особенно это актуально с учётом того, что "своя" альтернатива заглохла.

Тем не менее, известно, что Линус весьма предусмотрителен. И не одобрять
его политику жёсткого неприятия лицензий, помимо GPL, в ядро я не могу.
Ему виднее, чем это оправдано.
Но это остаётся лишь политикой, которая непосредственно влияет на
развитие системы. Его решение не говорит о качестве того, что он не
принимает.

EOFOF

12.01.2020 23:06, Victor Wagner пишет:

В Sun, 12 Jan 2020 22:39:47 +0300
artiom пишет:

Общие виртуальные машины и настройки Virtualbox у меня хранятся в
отдельном каталоге отдельного пользователя.
Для этого в его домашнем каталоге есть подкаталог с настройками Vbox.

Раньше, чтобы указать путь к настройкам, использовался
`/etc/vbox/vbox.cfg`.

Я давно не запускал VBox, он потребовался, я увидел, что машин нет.
`vbox.cfg` стал obsolete, да я и не помню, что там писать.

Подскажите, как сказать VBox, чтобы настройки он искал в указанном
месте?

VirtualBox это разработка Oracle (исходно Sun, но скуплена с потрохами
Oracle). Надо прочитать что тут недавно Линус Торвальдс писал про
другую разработку с той же историей - ZFS, после чего выкинуть нахрен
эту проприетарную поделку и пользоваться нормальынм QEMU с
KVM-акселерацией.

https://www.realworldtech.com/forum/?threadid=189711=189841

Re: Фризы графического интерфейса при записи на диск

Была давно такая же проблема.

Во-первых, если своп есть, понизить swapiness хотя бы до 5-10:

https://unix.stackexchange.com/questions/265756/desktop-completely-freezing-on-i-o-operations

Поиграйтесь с другими параметрами подсистемы памяти.

Также, посмотрите в сторону user preemption:

- https://kernelnewbies.org/FAQ/Preemption
-
https://stackoverflow.com/questions/5283501/what-does-it-mean-to-say-linux-kernel-is-preemptive

Покопайте описание параметров, может что путное найдёте:

$ grep PREEMPT /boot/config-$(uname -r)
# CONFIG_PREEMPT_NONE is not set
CONFIG_PREEMPT_VOLUNTARY=y
# CONFIG_PREEMPT is not set
CONFIG_PREEMPT_NOTIFIERS=y
# CONFIG_PREEMPTIRQ_EVENTS is not set
# CONFIG_PREEMPTIRQ_DELAY_TEST is not set

Ну и плюсом, планировщик ВВ на `noop` для SSD и `deadline` для обычных
дисков.
Раньше ещё частота таймера могла быть разная выставлена: на десктопах
1000, на серверах 100 Гц. Сейчас, вроде, не актуально.
Ну и планировщик процессов небольшую роль может играть (для Linux, хотя,
вряд ли актуально).

25.12.2019 01:20, Vitaly Polyakov пишет:

Еще один вопрос возник по использованию свежеустановленной системы.
Я поставил Debian Buster на SanDisk SSD U100 16GB (диск стоял в ноутбуке
как вторичный, скорее всего через шину pci express). Система установлена
на зашифрованном разделе с ext4.

При попытке сделать запись на диск, например, вот так:

sync; dd if=/dev/zero of=tempfile bs=1M count=1024; sync

Происходит зависание графического интерфейса (у меня стоит Mate). Тачпад
реагирует - курсор двигается, но при нажатии на кнопки тачпада и
клавиатуру ничего не происходит. На Ctrl+Alt+F1 тоже не реагирует.
Отвисает через некоторое время и работает дальше.

По умолчанию стоял scheduler mq-deadline. С ним фризы были еще чаще. Я
переключил scheduler на bfq , стало получше, но проблема все равно
чувствуется во время работы довольно часто (торрент файл сегодня качал
на 200 мегабайт, система опять начала лагать).

Куда смотреть, копать?

С уважением,
Виталий mai-tools.com

Virtualbox

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

Для этого в его домашнем каталоге есть подкаталог с настройками Vbox.

Раньше, чтобы указать путь к настройкам, использовался `/etc/vbox/vbox.cfg`.

Я давно не запускал VBox, он потребовался, я увидел, что машин нет.
`vbox.cfg` стал obsolete, да я и не помню, что там писать.

Подскажите, как сказать VBox, чтобы настройки он искал в указанном месте?

Re: Проиграна ли борьба за вычислительную свободу?

2019-08-13 Пенетрантность artiom

Ok, согласен, я уже прекратил.

10.08.2019 11:13, Alexander Danilov пишет:

09.08.2019 11:14, Eugene Berdnikov пишет:

On Fri, Aug 09, 2019 at 12:43:21AM +0300, artiom wrote:

On Thu, Aug 08, 2019 at 09:47:48AM +0300, artiom wrote:

Как ГБ может заставить чужой браузер
ПолярнаяЛиса отдать в JS тот фингерпринт, который должен быть у
интересного юзеру сайта, а не тот, который в подсунутом чекистами
сертификате?

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

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

инициативы в какой-то крошечной дырке мира совершенно неинтересны.

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

проблему технически, потому что её причины лежат в другой плоскости.

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

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

Паша Дуров вообще молодец, что борется против гэбешников и не соблюдает
законы РФ.
Не совсем, правда, понятно, почему он не борется против црушников и
соблюдает законы США.
Может потому, что бабки его в иностранных банках находятся и могут быть
в любой момент заморожены.

Может прекратим разводить "политпросвет для идиотов" в рассылке? Она всё
таки техническая.
Тут конечно политидиоты есть как и везде, но рассылка о другом и процент
идиотов всё же поменьше.

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

Точно так же на казахов можно найти действенные технические методы.

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

Re: Проиграна ли борьба за вычислительную свободу?

2019-08-13 Пенетрантность artiom


Так  не отрицаю, а просто констатирую факт: печально.


11.08.2019 16:32, Artem Chuprina пишет:

artiom -> debian-russian@lists.debian.org  @ Sat, 10 Aug 2019 07:40:08 +0300:

  > И это крайность, печально что "отстаивать интересны" однозначно 
ассоциируется
  > с "баррикадами".

О неработоспособности трех предыдущих коробок вы сообщили сами.

  >>>> Евгений, вы действительно не понимаете, что против доморощенных
  >>>> "технических методов", государство выставит десять технических и пять
  >>>> законов, причём за ваш счёт?
  >>> Вам действительно платят за троллинг в рассылке и попытки убедить 
технарей,
  >>> что они бессильны против государства с его "слугами народа", принимающими
  >>> один за другим неработающие законы-страшилки? Ну-ну, это забавно. :)
  >>
  >> Скорее на баррикады зазывает.
  >>
  >> Только недавно подумал: что-то давно в рассылке никакого срача не было, и 
на
  >> тебе.
  >>

Re: Проиграна ли борьба за вычислительную свободу?

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


10.08.2019 00:25, li...@mail.ru пишет:

09.08.2019 23:24, Eugene Berdnikov пишет:

On Fri, Aug 09, 2019 at 08:13:14PM +0300, artiom wrote:

Евгений, вы действительно не понимаете, что против доморощенных 
"технических методов", государство выставит десять технических и пять 
законов, причём за ваш счёт? 
Вам действительно платят за троллинг в рассылке и попытки убедить 
технарей, что они бессильны против государства с его "слугами народа", 
принимающими один за другим неработающие законы-страшилки? Ну-ну, это 
забавно. :) 


Скорее на баррикады зазывает.

Только недавно подумал: что-то давно в рассылке никакого срача не было, 
и на тебе.

Re: Проиграна ли борьба за вычислительную свободу?

09.08.2019 23:24, Eugene Berdnikov пишет:

On Fri, Aug 09, 2019 at 08:13:14PM +0300, artiom wrote:

09.08.2019 11:14, Eugene Berdnikov пишет:

On Fri, Aug 09, 2019 at 12:43:21AM +0300, artiom wrote:

On Thu, Aug 08, 2019 at 09:47:48AM +0300, artiom wrote:

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

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

Ваш замок вместе с забором вышибет ОМОН, а против шифрования применят
ректальный криптоанализ, если ваша неприкосновенность для этого не
обеспечена законом.

Да уж, оочень сильный ответ на вопрос в самой верхней цитате, о том как ГБ
заставит чужой браузер отдать в JS не тот фингерпринт, который ГБ нужен.
Оказывается... вышибанием дверей и ректальным криптоанализом! Надо полагать,
применительно к разработчикам браузеров и сотен тысяч сайтов по всему миру.
Вот так просто вылетит из крошечной задницы мира суровый казахский спецназ
и покажет всем несогласным на планете кузькину мать... Жуть. :))

Вы же сами привели такой пример.

Евгений, вы действительно не понимаете, что против доморощенных "технических
методов", государство выставит десять технических и пять законов, причём за
ваш счёт?

Вам действительно платят за троллинг в рассылке и попытки убедить технарей,
что они бессильны против государства с его "слугами народа", принимающими
один за другим неработающие законы-страшилки? Ну-ну, это забавно. :)

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

Дальше разговаривать не имеет смысла.

Re: Проиграна ли борьба за вычислительную свободу?


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


  Да пожалуйста! Законопослушного человека мало волнует то, что государство
  знает, с кем он разговаривал. Это для преступников выявление связей смерти
  подобно.


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

А все его "связи" также ставятся под наблюдение.
Вы от 30 годах XX века почитайте, хотя бы про СССР.



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



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




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



Это нормально. Оно происходит везде.
И каждый по мере возможностей тыкает на тех, кто играет в другой 
песочнице: https://www.kp.ru/daily/26327.2/3209366/

Re: Проиграна ли борьба за вычислительную свободу?


Нет, приходит сообщение, что письмо с отпиской надо отправить на адрес ... .
Это давняя тема.
Может уже поправили, тогда неплохо.

09.08.2019 13:01, Dmitry Alexandrov пишет:

artiom  wrote:

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


Серьезно?  Ни разу пока не сталкивался.  Или оно _молча_ заворачивается?

Re: Проиграна ли борьба за вычислительную свободу?





09.08.2019 22:33, Victor Wagner пишет:

В Fri, 9 Aug 2019 20:13:14 +0300
artiom  пишет:



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


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

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

Вот такие технические меры могут сработать.



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

А так, что толку?
Придут к вам домой и заберут всю технику без санкции, потому что 
используя ваш поломанный 0-day роутер, какой-нибудь Айрат Баширов 
написал о покраске заборов, и стеганография, да шифрование тут не помогут.

Re: Проиграна ли борьба за вычислительную свободу?

09.08.2019 11:14, Eugene Berdnikov пишет:

On Fri, Aug 09, 2019 at 12:43:21AM +0300, artiom wrote:

On Thu, Aug 08, 2019 at 09:47:48AM +0300, artiom wrote:

А последний яркий пример в IT это то как мессенджер Телеграмм вполне себе
техническими методами избавил нас от гэбешников, которые хотят
легимитизировать своё желание залезать в чью-то личную переписку.
И государство ничего сделать не может, только поливает Пашу Дурова
и Телеграмм грязью, мол, наркодилеры им пользуются, поэтому он плохой.

Да не смешите. Или вы серьёзно верите? Ну, в принципе, ясно: "Верую, ибо
абсурдно".

Точно так же на казахов можно найти действенные технические методы.

Евгений, вы действительно не понимаете, что против доморощенных
"технических методов", государство выставит десять технических и пять
законов, причём за ваш счёт?

У "защищающихся" же просто не будет ресурсов этому противостоять.
Если же это противоборство двух государств, вступает правило "щита и
меча", и начинается борьба.

Обычно проигрывает тот, у кого меньше ресурсов.

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

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

"Отрицательные" же техники не работают массово и требуют серьёзной
подготовки, следовательно, не решают проблему.

Это не значит, что технические методы использовать не стоит: в конечном
итоге всё сводится к ним.

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

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

Умею, иногда вопросы защиты решаю по роду деятельности.

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

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

Re: Проиграна ли борьба за вычислительную свободу?

А, ясно.
Думал вообще полный блэклист с запретом установки своего.
Понял.

09.08.2019 09:34, Victor Wagner пишет:

On Fri, 9 Aug 2019 00:39:17 +0300
artiom  wrote:

08.08.2019 10:31, Victor Wagner пишет:

On Thu, 8 Aug 2019 09:47:48 +0300
artiom  wrote:

   >   Как ГБ может заставить чужой браузер
   >   ПолярнаяЛиса отдать в JS тот фингерпринт, который должен
   > быть у интересного юзеру сайта, а не тот, который в подсунутом
   > чекистами сертификате?

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

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

Любопытно. А если пользователь развёртывает систему на изолированном
заводе, при этом все его сертификаты, пользуемые WebUI,
самоподписанные, но он не хочет, чтобы операторам браузер как-то
сообщал о "левом сертификате" (и не сообщал о реально "левом")?

Ну очевидно сертификат изолировнного от интернета CA не попадет в
блеклист, встроенный в браузер, именно потому, что разработчикам
браузера про этот сертификат никто не сообщит.

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

А так-то подобные MitM сертификаты для корпоративных систем -
стандартнейшая практика. Тут вам и антивирус, и intrusion detection.

Re: Проиграна ли борьба за вычислительную свободу?

On Thu, Aug 08, 2019 at 09:47:48AM +0300, artiom wrote:

P.S. Не надо в письмо включать полную копию предыдущего, здесь это
считается моветоном.

Ok. Только есть проблема: тут кривые настройки рассылки, и письмо, менее
какого-то размера заворачивается сервером рассылки.

Re: Проиграна ли борьба за вычислительную свободу?

08.08.2019 10:31, Victor Wagner пишет:

On Thu, 8 Aug 2019 09:47:48 +0300
artiom  wrote:

  >   Как ГБ может заставить чужой браузер
  >   ПолярнаяЛиса отдать в JS тот фингерпринт, который должен быть у
  >   интересного юзеру сайта, а не тот, который в подсунутом чекистами
  >   сертификате?

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

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

Любопытно. А если пользователь развёртывает систему на изолированном 
заводе, при этом все его сертификаты, пользуемые WebUI, самоподписанные, 
но он не хочет, чтобы операторам браузер как-то сообщал о "левом 
сертификате" (и не сообщал о реально "левом")?

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

Да это всё ясно. Тут одно государсство только возможно предполагать. 
Самое демократичное.

Была пара случаев когда национальные CA - какого-то из эмиратов
Персидского Залива и китайский пропихивали свои сертификаты в браузер,
а ПОТОМ были пойманы на использовании этих сертификатов для MiTM и с
позором выкинуты из ca-bundle.

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

Re: systemd-networkd

Нет, проблема не во мне.
Я отключил это - всё заработало.
Проблема в тех, кто это производит и тех дураках, кто их поддерживает.

08.08.2019 06:36, Igor Savluk пишет:

On 24/07/2019 14.03, Н. Артём wrote:

Есть система, которая имеет SSH сервер в initramfs (dropbear).
Интерфейсы связаны через бондинг в bond0, на котором этот сервер
работает.

Роутер выдаёт бондинг интерфейсу через DHCP фиксированный IP по MAC.

Когда система загружается, сервер убивается, бондинг разрушается и
запускается "нормальная" сетевая подсистема,

которая настраивает бондинг и поднимает OpenSSH.
MAC bond0 не изменяется, IP выдаётся тот же.

Когда был Stretch, не было проблем, всё работало.
Обновил на Buster - всё сломалось.

Выяснилось, что недавно пришедший на замену работающей подсистеме,
networkd-systemd всё ломает.
Если я не опускаю бондинг, его расхреначивает, и он требует IP для
каждого адаптера.
Когда я устанавливаю MAC вручную в его настройках (в двух местах -
настройках устройства bond0 и в настройках подключения),

он всё-равно устанавливает MAC на свой, и только потом на мной указанный.

В результате, роутер выдаёт другой IP (к тому моменту, ещё не истёк
срок действия предыдущего).

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

Отсюда вопросы (реально не в курсе, так что может не в тему):

- Что я делаю не так?
- Зачем поменяли работающее на это?
- Повинен в этом Леннар или это последователи?
- Что их не устраивало в resolv.conf?
- Стоит ли намекнуть маинтайнерам дистрибутива на то, что это какая-то
сильно непрозрачная, кривая и неочевидная в настройке херня?

Проблема только в тебе и твоих руках.

Re: Проиграна ли борьба за вычислительную свободу?

>   Как ГБ может заставить чужой браузер
>   ПолярнаяЛиса отдать в JS тот фингерпринт, который должен быть у
>   интересного юзеру сайта, а не тот, который в подсунутом чекистами
>   сертификате?

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

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

>   Свой ключ ещё надёжнее, потому как не передаётся удостоверяющему 
центру.

>   А токен, переданный третьей стороной, может быть этой же стороной слит
>   в ГБ по требованию госорганов. Им это намного легче сделать, чем добыть
>   ключ, который никогда не покидал хозяина.
>

Канал возможно считать надёжным.
А как заметил Виктор Вагнер, ключ возможно сгенерировать и на токене.
Или вы на ЦРУ работаете?
Просто это крайне неудобный вариант обмена ключами, плюс, законодательно 
могут обязать передавать ключи, например: "Заключил договор, получил 
токен - передай ключ, не передал - до трёх лет, за передачу без договора 
 - до пяти".

Эта проблема не решается технически.

06.08.2019 15:26, Eugene Berdnikov пишет:

On Tue, Aug 06, 2019 at 10:17:37AM +0300, artiom wrote:

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

   Теоретически любую такую проверку можно обойти, но практически

государству

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

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

  О, как интересно. Расскажите подробнее. Вот браузер ПолярнаяЛиса,
  который юзер себе поставил с плеймаркета, вот сертификат от ГБ,
  который ему пришлось поставить, чтобы выйти в интернет (без него
  чекисты не выпускают), вот код на JS, который читает поля сертификата
  и проверяет, скажем, фингерпринт. Как ГБ может заставить чужой браузер
  ПолярнаяЛиса отдать в JS тот фингерпринт, который должен быть у
  интересного юзеру сайта, а не тот, который в подсунутом чекистами
  сертификате?

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

Так уже есть токены.

  Токен это хранилище ключа, а клиента в модели x509 удостоверяет сертификат.
  Независимо от того, как клиент хранит свой ключ, в файле или в тукене.

Когда вам отдают токен, вы можете быть уверены, что там ключ именно
того, кто его передаёт (считаем, что механизмы передачи надёжны).

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

Re: Проиграна ли борьба за вычислительную свободу?

2019-08-06 Пенетрантность artiom

On Sun, Aug 04, 2019 at 09:41:20PM +0300, artiom wrote:

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

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

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

государству

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

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

Вариантов, как сделать подобное, - множество.
Эта проблема не решается технически.

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

Так уже есть токены.

Токен это хранилище ключа, а клиента в модели x509 удостоверяет сертификат.
Независимо от того, как клиент хранит свой ключ, в файле или в тукене.

Когда вам отдают токен, вы можете быть уверены, что там ключ именно
того, кто его передаёт (считаем, что механизмы передачи надёжны).

Кто-нибудь знает более простое решение?

Ну так известный же вам и всем остальным факт: всякая система основывается
на доверии, и не имея доверенного канала (хотя бы защищённого от MitM)
невозможно гарантированно надёжно обменяться ключами.

Нет, всё гораздо сложнее. Есть, например, известный факт, что любое сколь
угодно длинное число может быть разложено на простые множители. Вот только
времена всех известных алгоритмов для решения этой задачи так быстро растут
с длиной числа, что на этом основан метод шифрования RSA. Так что один лишь
факт разложимости числа на практике оказывается недостаточен, есть ещё
другие факторы, и они ЗНАЧИМЫ. Точно так же наличие MitM недостаточно,
чтобы читать любую переписку, оно даёт такую возможность лишь для цензоров
на сферических конях в вакууме, то есть в том случае, если другие значимые
факторы считать не существующими. :)

MitM с подменой ключей? Достаточно конечно. Как для чтения, так и для
искажения.

Re: Проиграна ли борьба за вычислительную свободу?

2019-08-04 Пенетрантность artiom

On Sat, Aug 03, 2019 at 05:27:07PM +0300, artiom wrote:

На этом фоне Казахстан со своим государственным MitM смотрится примерно
так же как его бомбардировочная авиация на фоне американской.

А что там снова властные дегенераты требуют?
Я упустил опять.

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

А, вона как. Так это давно уже. А прошивки тут причём?

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

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

Так уже есть токены.

> Кто-нибудь знает более простое решение?
>

Ну так известный же вам и всем остальным факт: всякая система
основывается на доверии, и не имея доверенного канала (хотя бы
защищённого от MitM) невозможно гарантированно надёжно обменяться ключами.

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

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

Так что, увы, дальше будет только хуже, если иммунитет не заработает.

Re: Mozilla Firefox как несвободная программа

2019-08-03 Пенетрантность artiom

Но в репозитории firefox торчит в секции main...

31.07.2019 06:05, Dmitry Alexandrov пишет:

artiom wrote:
Victor Wagner wrote:

Более того, формально opensource продукты, такие как мозилла тоже в общем-то нарушают
свободу N1. Потому что дизайн там такой запутанный что на выяснение того как там что
устроено и "change it so it does computing as you wish" уйдут годы.

Конкретно насчёт этого, вы не правы. Тот же Столлман достаточно серьёзно
относится к терминологии.

Боюсь, что Виктор Бертильевич неправ в первую очередь в другом.

Если под «Мозиллой» он по старой памяти имеет в виду «Файрфокс» — тот браузер,
который можно загрузить с https://mozilla.org, то это просто несвободная
программа, _проприетарщина_ безо всяких оговорок про «неформально». Такая же
по сути как Гуглохром: где-то там есть какие-то свободные исходники, но готовый
продукт нельзя ни толком просто распространять, ни уж тем более распространять
в измененном виде.

Если кого-то эта мысль удивляет (ибо не может же Википедия врать!), то вот
выдержка из лицензии на нее:

| You may distribute unaltered copies of Mozilla Firefox from Mozilla.org
without express permission from Mozilla as long as you comply with the
following rules:
|
| — You may not charge for Firefox. That means:
| · Distribution may not be subject to any fee.
| · Distribution may not be tied to purchasing a product or service.
| You may not collect personal information in the context of your
distribution of Firefox.
| — You may not add to, remove, or change any part of Firefox, including
the Mozilla trademarks themselves. For example, you may not add any extensions
to Firefox.
| — You may not modify the installation process of Firefox or use it to
install any other themes, plugins, extensions, or software.
| — We suggest that if you want to distribute Firefox, you do so by linking
to official downloads of Firefox at Mozilla.org to help ensure safe, reliable
downloads. If you wish to directly distribute copies of Firefox yourself, you
must distribute the latest stable version available at Mozilla.org.
| — When distributing you must distribute the most recent version of
Firefox.
| — For Android versions of Firefox that you are distributing on a device:
(1) the device must have at least 512MB of RAM; and (2) if the device does not
have Google Play installed, you must have a means for providing the user with
Firefox updates as they are released by Mozilla (see the release calendar).
— https://www.mozilla.org/en-US/foundation/trademarks/distribution-policy

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

Re: Проиграна ли борьба за вычислительную свободу?

2019-08-03 Пенетрантность artiom

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

Ну это, кстати, нам всем Соединенные Штаты крепко подгадили. Еще
пару лет назад купить «коробочку с вайфайем» по крайней мере бытового
класса, где бы не только драйвер, но и прошивка радиомодуля была бы
свободной, проблем не составляло. А теперь их просто _запрещено_
продавать. В США запрещено, но того более чем достаточно.

Ну оплот свободы и либерализма любит в этом плане подгадить. То
криптографию экспортировать запретят, то DRM на законодательном уровне
потребуют, то вот это. Впрочем ЕС в этом плане им достойный соперник.

А что там снова властные дегенераты требуют?
Я упустил опять.
Почему нельзя открытые прошивки с открытыми драйверами продавать?

Re: BCO System Cryptographic Plugin

2019-07-26 Пенетрантность artiom


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

Либо попробовать токен пробросить в виртуалку.
Это ж USB, ему должно быть не важно, что не физическая машина.


26.07.2019 08:30, Artem Chuprina пишет:

artiom -> debian-russian@lists.debian.org  @ Thu, 25 Jul 2019 23:18:12 +0300:

  > Я использовал его не для логина в банк, а для логина администратора в
  > разрабатываемом комплексе, но через стандартную библиотеку для pkcs11 (либо
  > слегка доработанную) и свой клиент, её использующий.
  > С банками не знаю.
  > Лично по-моему, токен - это overkill для банка, хотя может я и не прав.
  > Если вы там не держите миллионы, он не нужен.
  > А если вы держите миллионы в российском банке, - тем более.

Я так подозреваю, что в режиме для предприятий не важно, держите вы в
российском банке три миллиона или три рубля. Банк требует только такой
авторизации, и фсё. Причем, скорее всего, он бы, может, и рад иначе, да
от него этого требует Центробанк.

Физлицам проще.

  > 25.07.2019 21:58, Коротаев Руслан пишет:
  >> artiom  пишет:
  >>
  >>> КриптоПРО - отдельный пакет.
  >>> Токены к нему отношения не имеют.
  >>> Как минимум, на Linux я использовал RuToken и JaCarta.
  >>
  >> Да, я в курсе что рутокен можно использовать на linux. На портале какого
  >> банка вы смогли залогинтся используя только рутокен, без криптопро и
  >> прочих криптопровайдеров?
  >>

Re: BCO System Cryptographic Plugin

Я использовал его не для логина в банк, а для логина администратора в 
разрабатываемом комплексе, но через стандартную библиотеку для pkcs11 
(либо слегка доработанную) и свой клиент, её использующий.

С банками не знаю.
Лично по-моему, токен - это overkill для банка, хотя может я и не прав.
Если вы там не держите миллионы, он не нужен.
А если вы держите миллионы в российском банке, - тем более.

25.07.2019 21:58, Коротаев Руслан пишет:

artiom  пишет:


КриптоПРО - отдельный пакет.
Токены к нему отношения не имеют.
Как минимум, на Linux я использовал RuToken и JaCarta.


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

Re: systemd-networkd


Более того, формально opensource продукты, такие как мозилла тоже
в общем-то нарушают свободу N1. Потому что дизайн там такой запутанный
что на выяснение того как там что устроено и "change it so it does
computing as you wish" уйдут годы. А за эти годы оно будет три раза
переделано. Поэтому если ты не имеешь возможности тратить на работу над
конкретным продуктом значительную часть своего времени, ты не сможешь
"change it so it does your computing as you wish."


Конкретно насчёт этого, вы не правы. Тот же Столлман достаточно серьёзно 
относится к терминологии.

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

Re: systemd-networkd


> Правильно думаете. Я имею слишком большой опыт  программирования на
> этому уродце, чтобы заниматься этим в конце второго десятилетия XXI
> века, когда есть Go и Rust.

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

Rust, увы, не взлетел, и похоже, что сейчас уже не предполагается.


> А код на C++ который существует ну слова доброго не стоит (ну скажем
> мозилла или qt).

Mozilla я не копал, а Qt вполне приятная библиотека, подозреваю, чем она 
вас не устроила, однако в целом, достаточно неплоха.



> Опять же код на столь безумно устаревших языках интересен только если у
> нас есть огромная старая codebase (ну скажем mozilla или qt). А эта
> codebase все равно была написана по стандартам конца прошлого века.
> Так что продолжать в том же духе не столь уже сложно

Похоже, вы очень давно не программируете на C++.
Сейчас это другой язык, и от Стандарта 2003 года сильно отличается.
А насчёт "устарелости" - он в пятёрке наиболее популярных в списке TIOBE.


> Потому  что мы в debian-russian. Были бы во freebsd-russian или
> macos-russian, шла бы речь про clang. Ну и понятно на какой платформе
> шла бы речь про MSVC.
>

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



> Вот совместимость с линейкой компиляторов очень способствует "чтобы оно
> не падало в местах, где...". Разные компиляторы вылавливают в качестве
> Warning-ов разные огрехи. И если все их гонять с -Werror и аналогами...

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


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

Это уже вопрос наличия ресурсов.


> Так борьба с systemd тоже требует времени. Вопрос в том, на что
> потратить время - на борьбу с поделиями поттерингов или на создание
> альтернативы им.
>

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


> Собственно проблема devuan как раз в том, что люди предпочитают бухтеть
> про то, какой плохой поттеринг, вместо того чтобы засучить рукава и
> сделать свое.

Зачем? Уже много делали. "Выбрали" творение поттеринга, потому что RH.


> Столлман 35 лет назад не бухтел про то какая плохая
> Symbolics, а писал патчи для LMI.
>

Столлман живёт в США, и он мог себе позволить бросить престижный и 
дорогой ВУЗ, не опасаясь того, что ему будет негде жить и нечего есть.

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



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

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

Хотите мне сказать, что это плохо? :-/
Так и вы не святой, чтобы праведно судить: делаете то, за что вам платят 
заказчики.



> Объективная причина тут одна - люди не хотят в этом участвовать.
> Вы не хотите, я не хочу (разок сунулся, остался неуслышанным и плюнул,
> все равно мне дистрибутивы с systemd поддерживать, так что знать его
> придется).
>

Ну так о чём говорить? А поттеринг сунулся - не услышали, сунулся - 
послали, сунулся - отгородились.

Но он делал это снова и снова, пока не пробился.


>> Ну и прекращение их выхода для старых версий библиотек (та же OpenSSL
>> в конце года выкидывает какую-то версию) и прекращение официальной
>> разработки и поддержки старых диалектов, типа Python 2, на котором в
>> Devuan много что есть, тоже не стимулирует к переходу.
>
> Подавляющее боьшинство крупных корпоративных заказчиков использует
> системы на базе RHEL 6 и 7. Которые обе гораздо старее Devuan. Так что не
> беспокойтесь по поводу прекращения поддержки софта менее чем
> десятилетней давности.

Да как факт в openssl (по-моему, 1.12.x) больше патчей не будет.
Это риск по SDL.
Его заставляют менять, следовательно, придётся обновлять то, что в 
образах, а с учётом завязок других компонентов, надо обновлять саму ОС.



25.07.2019 10:12, Victor Wagner пишет:

On Thu, 25 Jul 2019 09:04:21 +0300
artiom

Re: BCO System Cryptographic Plugin

КриптоПРО - отдельный пакет.
Токены к нему отношения не имеют.
Как минимум, на Linux я использовал RuToken и JaCarta.

25.07.2019 17:06, Коротаев Руслан пишет:

Дмитрий Фёдоров пишет:

Нужно было думать об этом раньше, когда выбирали банк.
Банки с ДБО без винды и джавы существуют, подсказывать не буду.

А может подскажите?

Я в своё время пробовал разобраться с «отчественной криптографией» и
ничего не понял. Там помимо токена, нужно покупать лицензию криптопро и
без windows это нормально работать не будет. Как я понял, это криптопро
постоянно что-то сканирует, куда-то посылает, оно пытается понять в
каком окружении находится — виртуалка или реальное железо, от этого
зависит тип лицензии. Короче, что-то как-то...

Если хотите, можете написать названия банков в личку. Но если есть
нормальный банк, который выдает сертификаты ДБО, которые можно загрузить
в токен (рутокен или алладин), а токен в свою очередь можно подключить к
firefox через PKCS#11 [1], то указать название такого банка в рассылке
будет не реклама, а помощь всем людям, которые опасаются мошенников.

[1]:
https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/pkcs11

Re: systemd-networkd


> Прописывать адрес статически.

А, ну да, в IPv6 у каждого диапазон же.
Можно, конечно, особенно внутри сети.
Но сейчас всё настроено с IPv4 и автоматической выдачей адресов, не 
хочется переделывать.


> Здесь все не так. И война за свободу ПО, которую начал Столлман в
> середине 80-х - проиграна.

Хм, надо будет почитать...


> Если ты не можешь написать софт, который компилируется любым GCC начиная
> с 4.6 и конччая 9.1, то ты не умеешь программировать. Если ты скачал
> откуда-то такой софт, сотри немедленно. Потому что его автор не умеет
> программировать, и отсутствие поддержки компилятора имеющейся у тебя
> версии, скорее всего не единственная и не главная его проблема.
>

Ну это излишне сильное утверждение.
Я так думаю, вы на C++ не программируете.

Я могу написать такой софт, но делать этого не буду, потому что моя 
задача - не совместимость кода с линейкой компиляторов (и почему gcc, а 
не clang, MSVC, icc, ну и прочие?), а внятное донесение человеку идеи.
Причём так, чтобы это ещё и быстро работало, не падая в местах, где 
кривые внешние данные или нехватка ресурсов.


И я буду пользоваться возможностями 17 стандарта (тем же std::variant, 
если потребуется), а не тащить для этого костыли из Boost и десятка 
отдельных библиотек, только для того, чтобы поддержать сборку 
компилятором 10 летней давности.



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

Ну проблема в том, что это требует времени.
А обновление зависимостей, среди которых будет glibc, от которого 
зависит всё, требует ещё больше времени.
При этом, если моей задачей было что-то от сборки компилятора в Devuan 
отличное, где-то на полпути я задумаюсь, что занимаюсь не тем, чем 
требовалось.


В случае, если у меня не будет выбора, я просто возьму Docker-образ с 
новым компилятором.

Но привычка.


> Чай не Solaris 9 где собрать gcc так, чтобы им потом можно было 
собрать openssl было еще тем квестом, и требуемые для этого патчи к 
crt1.o почему-то gcc-шная команда принимать отказывалась.


Я даже представляю их мотивировку...


> Впрочем, я про Solaris еще могу страшных сказок порассказывать, как 
там gcc 5.3 работает с 128-битными целыми, передаваемыми в функцию.

> Помнится мы зимой в pgsql-hackers на эту тему неделю ругались, пока
> наконец не написали более-менее приличный тест для configure.
>
> Вообще, конечно, плакаться по поводу старых компиляторов в devuan,
> которому без году неделя

Да я не плачусь, а указываю вам на вполне объективные причины, которые 
переход на Devuan блокируют.
Кроме того, я не уверен, что все патчи безопасности из Debian туда 
перекочевали.
Ну и прекращение их выхода для старых версий библиотек (та же OpenSSL в 
конце года выкидывает какую-то версию) и прекращение официальной 
разработки и поддержки старых диалектов, типа Python 2, на котором в 
Devuan много что есть, тоже не стимулирует к переходу.



> в ответе человеку, который вынужден
> поддерживать софт для RHEL 6, SLES 11sp4 и МСВС-6.3 (про эльбрусы я
> вообще полмолчу)...
>

Так кто же вас заставляет поддерживать всякое старьё?
Если вам это нравится, - дело хозяйское: есть и люди, которые VAX с 
OpenVMS разворачивают в гараже.
Но я же не занимаюсь поддержкой таких систем, и то, что где-то ещё 
работает МСВС 3 с ядром версии 2.9, меня не заставляет восхититься 
относительной новизной Devuan, отставшего года на 4.



25.07.2019 00:54, Victor Wagner пишет:

В Wed, 24 Jul 2019 21:20:24 +0300
artiom  пишет:


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

Я же прописал для bond интерфейса, по крайней мере...
У вас MAC не прописаны, кстати.


Я ж говорю - у меня конфигурация проще. Мне не надо менять mac
интерфейсу.
  

  > У меня, правда, более простая конфигурация - не бондинг, а бридж
  > (куда потом включаются tun-интерфейсы qemu-шных виртуалок и veth
  > lxc-шных контейнеров. Зато IPv4 у него статический (потому как
  > серый) а ipv6 - динамический (потому как globally routable).

В том и дело: не хочу статический, хочу DHCP, но всегда одинаковый.


  > ipv6 - динамический (потому как globally routable).

Если это сервер, как жить?


Прописывать адрес статически.




  > Потому что есть компания людей, которая считает, что Debian is not
  > about choice. И это они как-то открытым текстом в debian-devel
  > декларировали.

Скажите, а мне одному кажется, что здесь что-то не так?


Здесь все не так. И война за свободу ПО, которую начал Столлман в
середине 80-х - проиграна.


Вот, например, идеологии Linux это не противоречит?


Linux это ядро. Его идеологии совершенно пофиг как в юзерспейсе
конфигурируются интерфейсы.

Вот идеологии GNU-системы, описанной Столлманом в статье Opening The
Software toolbox оно противоречит, и еще как.

Но я же говорю - битва за свободу ПО проиграна.

Re: systemd-networkd

2019-07-24 Пенетрантность artiom


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

Я же прописал для bond интерфейса, по крайней мере...
У вас MAC не прописаны, кстати.
Да и он его меняет, просто не сразу, видимо...


> У меня, правда, более простая конфигурация - не бондинг, а бридж (куда
> потом включаются tun-интерфейсы qemu-шных виртуалок и veth lxc-шных
> контейнеров. Зато IPv4 у него статический (потому как серый) а
> ipv6 - динамический (потому как globally routable).

В том и дело: не хочу статический, хочу DHCP, но всегда одинаковый.


> ipv6 - динамический (потому как globally routable).

Если это сервер, как жить?


> Потому что есть компания людей, которая считает, что Debian is not about
> choice. И это они как-то открытым текстом в debian-devel декларировали.

Скажите, а мне одному кажется, что здесь что-то не так?
Вот, например, идеологии Linux это не противоречит?
Debian, конечно, не Linux, однако ядро основное (а сейчас уже может и 
единственное)...



> Увы, не поможет. Те, кто согласны с этим утверждением ушли на devuan.

Который отстаёт на две версии от и так далеко не свежайшего Debian (даже 
с учётом бэк-портов), что особенно актуально с выходом нового 
компилятора (ага, "компильте в Docker или на CI", но мне это иногда 
менее удобно).



24.07.2019 15:03, Victor Wagner пишет:> On Wed, 24 Jul 2019 14:03:34 +0300
> Н. Артём  wrote:
>
>> Есть система, которая имеет SSH сервер в initramfs (dropbear).
>> Интерфейсы связаны через бондинг в bond0, на котором этот сервер
>> работает. Роутер выдаёт бондинг интерфейсу через DHCP фиксированный
>> IP по MAC.
>>
>> Когда система загружается, сервер убивается, бондинг разрушается и
>> запускается "нормальная" сетевая подсистема, которая настраивает
>> бондинг и поднимает OpenSSH. MAC bond0 не изменяется, IP выдаётся тот
>> же.
>>
>> Когда был Stretch, не было проблем, всё работало.
>> Обновил на Buster - всё сломалось.
>>
>> Выяснилось, что недавно пришедший на замену работающей подсистеме,
>> networkd-systemd всё ломает. Если я не опускаю бондинг, его
>> расхреначивает, и он требует IP для каждого адаптера. Когда я
>
> C этим мне все-таки удалось побороться.
>
> Можно прописать ему (в отдельном файлике для каждого интерфейса) что
> надо и что не надо от этого интерфейса требовать.
>
> У меня, правда, более простая конфигурация - не бондинг, а бридж (куда
> потом включаются tun-интерфейсы qemu-шных виртуалок и veth lxc-шных
> контейнеров. Зато IPv4 у него статический (потому как серый) а
> ipv6 - динамический (потому как globally routable).
>
> Получилось примерно так:
> ==> /etc/systemd/network/br0.netdev <==
> [NetDev]
> Name=br0
> Kind=bridge
>
>
> ==> /etc/systemd/network/br0.network <==
> [Match]
> Name=br0
> [Network]
> Address=192.168.217.1/25
> Gateway=192.168.217.63
> Broadcast=192.168.217.128
> DHCP=ipv6
> DNS=127.0.0.1
>
> ==> /etc/systemd/network/eth0.network <==
> [Match]
> Name=eth0
> [Network]
> Bridge=br0
> DHCP=no
>
> Вообще в *.network можно вписать Unmanaged=yes и
> тогда, по утверждению документации, systemd-networkd вообще не будет
> трогать этот интерфейс.
>
> И можно будет конфигурировать его через ipupdown (это же имеется в виду
> под старой подсистемой), не снося systemd-networkd.
>
> У меня, правда, сходу не получилось. Потому что я не ожидал от ini-style
> конфигурационного файла того, что пробелы вокруг знака равенства
> недопустимы.
>
>> Отсюда вопросы (реально не в курсе, так что может не в тему):
>>
>> - Что я делаю не так?
>> - Зачем поменяли работающее на это?
>> - Повинен в этом Леннар или это последователи?
>
> Потому что есть компания людей, которая считает, что Debian is not about
> choice. И это они как-то открытым текстом в debian-devel декларировали.
>
>> - Что их не устраивало в resolv.conf?
>> - Стоит ли намекнуть маинтайнерам дистрибутива на то, что это
>> какая-то сильно непрозрачная, кривая и неочевидная в настройке херня?
>
> Увы, не поможет. Те, кто согласны с этим утверждением ушли на devuan.
>
> --
>

Re: btrfs?

2018-11-10 Пенетрантность artiom



  >> При этом поддержка ext4 в линуксе не в пример лучше :) Включая,
  >> например, тот момент, что дистрибутивный пакет умеет цеплять ZFS только
  >> если инитом работает systemd, а systemd инитом весьма хреново
  >> работает.

  > Ну как-бы он сейчас меинстрим, хоть как-то да работает.

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

Подозреваю, что проблема в том, что отслеживать зависимости при загрузке
systemd на самом деле не умеет, а "как повезет". Т.е. подозреваю, что
проблема в этом, потому что про "как повезет" есть уверенность.



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

Возможно, что именно там зависимости прописаны криво.


  >> Описанная проблема с нецеплянием одного из томов — не
  >> единственная проблема с systemd на этой машине. Это я уж молчу про танцы
  >> с рутом на ZFS. Я их один раз станцевал, но результат мне не шибко
  >> нравится.

  > Рут на ZFS, вполне устраивает, grub на ZFS загружает ядро с ZFS тома.

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



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

Re: btrfs?

2018-11-08 Пенетрантность artiom

03.11.2018 20:27, Artem Chuprina пишет:

artiom -> debian-russian@lists.debian.org @ Sat, 3 Nov 2018 16:10:09 +0300:

> Пользуюсь ZFS на Debian Linux с 17 года в NAS, пока всё ok. Две системы
> подобной сложности вряд ли нужны. Одна в продакшне, другая между альфа и
бета
> версиями уже долго, потому если требуется подобный функционал, ясно что
> выбирать.

Ну вот у меня, например, при загрузке системы упорно не монтируется один
из томов ZFS. Если залогиниться после загрузки и сказать zfs mount -a,
то молча монтируется. Отличается от остальных тем, что там попрошено
case insensitive имена файлов (это exchange, в первую очередь для винды)
и задействованы ACL.
Как следует разобраться с проблемой руки не доходят, ибо сервер на шкафу
и монитор к нему цеплять неудобно.

А монитор-то зачем, если залогиниться возможно без примонтированного тома?
Кстати, точка монтирования пустая?

Офф-бэнд дефрагментацию блочного уровня ZFS, в отличие от btrfs, не
умеет.

Да, есть такое, предлагают делать через zfs send, но велик ли уровень
фрагментации для большинства задач?

Под ин-бэнд требования к железу невменяемые.

Это про что? Про дедап?

А прочие плюшки ZFS
по сравнению с той же ext4 как-то применить не удается — машинка
слабенькая, без ECC, диск один, так что чексуммы все равно лучше держать
внешние, и проверять после скидывания на бэкапный винт.

Помню, тема была, и в ней таки пришли, что лучше ZFS.
Но да, без ECC не стоит. Да и ext4 в данном случае ничего гарантировать
не может.

При этом поддержка ext4 в линуксе не в пример лучше :) Включая,
например, тот момент, что дистрибутивный пакет умеет цеплять ZFS только
если инитом работает systemd, а systemd инитом весьма хреново
работает.

Ну как-бы он сейчас меинстрим, хоть как-то да работает.

Описанная проблема с нецеплянием одного из томов — не
единственная проблема с systemd на этой машине. Это я уж молчу про танцы
с рутом на ZFS. Я их один раз станцевал, но результат мне не шибко
нравится.

Рут на ZFS, вполне устраивает, grub на ZFS загружает ядро с ZFS тома.

Re: btrfs?

2018-11-03 Пенетрантность artiom

Пользуюсь ZFS на Debian Linux с 17 года в NAS, пока всё ok. Две системы 
подобной сложности вряд ли нужны. Одна в продакшне, другая между альфа и 
бета версиями уже долго, потому если требуется подобный функционал, ясно 
что выбирать.


02.11.2018 18:19, Artem Chuprina пишет:

Угу, осознал. Всем спасибо, переформатировал в ext4 и ограничусь
перелинковкой средствами jdupes. Из положительного: в процессе чтения
про дедупликацию у btrfs выяснил, что существуют готовые инструменты для
такой перелинковки (не зависящие от btrfs), не надо писать :)

  >> Граждане, а как у нас нынче с надежностью btrfs? А другими тараканами?

  > Пару лет назад оно вело себя странно. Данные вроде не терял из-за нее,
  > но периодически приходилось делать rebalance. Сейчас живу с ней (ядро
  > 4.18) и вроде всё устраивает. Кроме того, она активно используется в
  > качестве backend для sbuild очень много у кого.


  > [gq@dwarf:~/ya/sdc]$ mount | grep btrfs
  > /dev/mapper/dwarf-root on / type btrfs 
(rw,relatime,ssd,space_cache,subvolid=5,subvol=/)
  > /dev/mapper/dwarf-chroot on /srv/chroot type btrfs
  > (rw,relatime,compress=zlib:3,ssd,space_cache,subvolid=5,subvol=/)
  > /dev/mapper/dwarf-home on /home type btrfs 
(rw,relatime,ssd,space_cache,subvolid=5,subvol=/)
  > /dev/mapper/dwarf-tmp on /mnt type btrfs 
(rw,relatime,ssd,space_cache,subvolid=5,subvol=/)

  >> Или ну его пока нафиг, и пожить на старой доброй ext4? Задача - ФС под
  >> домашний файловый/бэкапный сервер. 8 TB. Его собственное содержимое
  >> бэкапится, увы, пока нерегулярно. Рейд тоже пока увы. Во-первых,
  >> нетбабла (диск такого объема не три копейки стоит), а во-вторых, в той
  >> машинке быстрый SATA-выход один.
  > Под надежный сторадж я использую ext4. Он же надёжный =)

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

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

Re: systemd halt

2018-10-13 Пенетрантность artiom


Спасибо. Тоже эта неприятная мелочь раздражала.

13.10.2018 16:27, Evgeny Zubok пишет:

Evgeny Zubok  writes:


sergio  writes:


Как правильно выключать debian с systemd?

говорю sudo halt, система доходит до "reboot: System halted" и всё.


Не пользуюсь systemd, поэтому поинтересуюсь: systemd каким-нибудь
образом использует прежние настройки системы из
/etc/default? Предполагаю, что нет. Но если использует, то там есть
файлик /etc/default/halt, в котором надо указать HALT=poweroff. Тогда он
по halt будет выключать машину.


Если что, то эта переменная среды описана в man shutdown в разделе HALT
OR POWEROFF в конце. В общем, задача сводится к тому, чтобы установить
эту переменную среды при помощи этой вашей systemd, то есть найти
правильное место.

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




06.10.2018 20:39, Victor Wagner пишет:
> On Sat, 6 Oct 2018 15:49:18 +0300
> artiom  wrote:
> 
> 
>>
>> Т.е., всё-таки на первое место выходит доступность, а
>> конфиденциальность данных на втором, и они не сильно чувствительны к
>> этой угрозе?
> 
> 
> Проблема тут не в том, сильно ли чувствительны данные к угрозам
> конфиденциальности, а в том что разные данные к ним чувствительны очень
> по разному.
> 
> Нарушая фидошную традицию и вспоминая, что написано в subj, а там
> написано "Доступ к медиатеке", мы можем рассмотреть угрозы
> конфиденциальности для данных медиатеки.
> 
> В медиатеке у нас лежат данные, которые вообще в принципе опубликованы,
> и которые потенциальному атакующему доступны и из другого места.
> 

Да не, с медиатекой всё понятно.


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

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

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

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

Не секрет, как они используют данные и какие:
https://privacy.google.com/intl/ru/take-control.html?categories_activeEl=sign-in

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

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

Рассматривают и предоставляют. Как известно, законы везде разные.

Плюс, ваши данные потенциально могут утечь:
https://tproger.ru/news/facebook-87-million-leak/

Если возможно на Facebook, то почему не в гугле? К тому же, google.docs
были недавно яндексом проиндексированы.

И есть немало компаний и "аффилированных лиц", которым гугл передаёт данные.

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




06.10.2018 13:46, Victor Wagner пишет:
> 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?
> 

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

>> к /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 - это его имя
> 

Примерно так у меня и есть, в целом: https://habr.com/post/359344/

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

Хм... Т.е., я завожу в своей зоне ещё три домена. При обращении к ним,
меня перекидывает на ещё один обратный прокси, который делает проброс
только если пользователь авторизован?

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

А причём здесь вообще телеграм?

06.10.2018 16:01, Евгений Кабанов пишет:
>> Впрочем, несколько ушли от темы доступа к медиатеке.
>> Музыка и фильмы - это явно не те данные, которые я хочу защитить ото
>> всех. Мне нужно предоставить доступ на запись/изменение с аудитом для
>> некоторых авторизованных людей.
>> И на чтение для большинства авторизованных.
>> Сейчас пока думаю насчёт webdav с LDAP, чуть позже займусь на
>> практике.
>> Может имеются ещё варианты?
> 
> Есть простые, но возможно не правильные решения:
> 1. грузите контент в приватный канал телеги;
> 2. назначаете админов с нужными правами (на изменение);
> 3. просто подписываете всех остальных, кого решите;
> 4. поддерживаете состав подписчиков и админов в соответствии с
> собственной политикой. 
>

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

Впрочем, несколько ушли от темы доступа к медиатеке.
Музыка и фильмы - это явно не те данные, которые я хочу защитить ото всех.
Мне нужно предоставить доступ на запись/изменение с аудитом для
некоторых авторизованных людей.
И на чтение для большинства авторизованных.
Сейчас пока думаю насчёт webdav с LDAP, чуть позже займусь на практике.

Может имеются ещё варианты?

04.10.2018 20:44, artiom пишет:
> Требуется организовать доступ к медиатеке, позволяющий нескольким
> пользователям переименовывать, удалять и, главное, добавлять файлы.
> 
> Медиатеку показываю, используя Emby, но с добавлением там всё плохо, а о
> полноценном управлении, как файловой структурой, и говорить нечего.
> 
> При этом, условие такого, что пользователи авторизуются через LDAP.
> 
> Один из вариантов был - использовать файловые менеджеры в
> докер-контейнере, типа sprut.io, но с LDAP там всё плохо.
> Ещё один вариант, который я серьёзно рассматривал - использовать sshfs и
> системный pam-ldap модуль. Но встали вопросы: как не дать пользователю
> выполнять команды и ограничить просмотр дерева не выше того каталога, в
> котором хранится медиатека?
> 
> Есть какие-то варианты того, как эту задачу решают белые люди?
> Что посоветуете?
> И по pam-ldap вопросы тоже актуальны.
>

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




06.10.2018 13:53, Victor Wagner пишет:
> 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 атаку вашему сайту.
> 
> От этих угроз (угроз доступности) следует защищать ЛЮБЫЕ данные.
> 

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

> 4. От bingbot-а, который запросто может устроить DoS атаку вашему сайту.
>

Какая "прелесть".

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

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

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

Он использует эти данные не только для рекламы.

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

> On 06/10/18 04:59 AM, artiom wrote:
>> Не в тему.
> 
> Почему же? У вас душ к примеру на улице находиться? полностью прозрачный?
> 
Потому что вопрос был не о душе на улице и не о философских проблемах
необходимости защиты информации.

>> Вопрос совершенно конкретный: "От кого вы собрались защищаться?"
> 
> В том то и дело. Вопрос не верен. Не от кого. А почему (ну или зачем). А
> ответ уже есть :)
> 
Вопрос совершенно верен. Думаю, что эту тему я знаю несколько лучше вас.
Если хотите формально: какова модель нарушителя?

>> Если вы этого не понимаете, то как вы определите перечень мер защиты?
> 
> Очень просто. Задача обеспечить конфиденциальность целостность и
> доступность.
> 
От кого? Кому? Для чего? На каком уровне? Вы говорите общими словами, а
они дают мало.

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




06.10.2018 14:18, D. H. пишет:
> On 06/10/18 05:53 AM, Victor Wagner wrote:
>> 3. От очередной драчки роскомнадзора с Дуровым при которой ваше облако
>> может случайно попасть под раздачу, оказавшись в одном /16 блоке с
>> телеграмовской прокси.
> 
> Вот это я пошел гуглить. Что-то пропустил похоже.
> 
Совсем немного: блокировки миллионов адресов, судебные иски и срач в
сторону РКН.

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

> On 06/10/18 04:58 AM, artiom wrote:
>> От задач. Если вы хотите, например, имея облако, отдать файл по ссылке
>> кому-то постороннему.
> 
> Боже упаси и сохрани от хранения важной инфы в облаках. (икону наверное
> надо ещё приложить)
> 
В своём облаке.
Что такое "важная инфа"?
Вы как-то измеряете степень важности?

>> Как вы это сделаете, если NAS доступен только через VPN?
> 
> А я сказал только?
> 
Ну ok, доступен через VPN для манипуляции файлами.
А манипулировать ими хочу не только я.
Кроме того, надо поднимать VPN на NAS, что само по себе задач не решит,
лишь откроет другие пути, которые без VPN не работают.

>> Вы будете всех переводить на VPN?
> 
> Это даже телефоны умеют. В чем проблема?
> 
В том, что это надо сделать тому, кто это делать не хочет.
Это переусложнение.
Вам надо поделиться с человеком данными, а вы ему не только ссылку, но
"поставь VPN".

> Итого:
> 
> Это не проблема VPN, это проблема внезапно возникшего человека. У
> которого нет в данный конкретный момент VPN. И с ним вопрос будет решен
> индивидуально, как ему и мне удобнее.
> 
Опять же: каковы условия? Есть пять человек, которым этот VPN нафиг не
сдался. Онис гитом, например, работают.
Всё по SSH, интерфейс по HTTPS. Зачем тут VPN?

> Как правило таки файлы умещаются в обычный email.
> 
> Всё остальное. Ну вопрос только к самой информации. Смотря что вы хотите
> раздавать.
> 
И это тоже: что и кому.

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

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

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




06.10.2018 00:13, D. H. пишет:
> On 05/10/18 02:33 PM, artiom wrote:
>> VPN привносит другие проблемы, которые мне не требуются.
> 
> Ну со мной поделитесь, я пока не столкнулся но возможно удаться избежать
> этого в будущем так как буду иметь в виду и думать над потенциальным
> решением.
> 
От задач. Если вы хотите, например, имея облако, отдать файл по ссылке
кому-то постороннему.
Как вы это сделаете, если NAS доступен только через VPN?

Вы будете всех переводить на VPN?


>> Не будем спорить.
> 
> И не собирался.
>

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




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., обращающиеся
к /bla/bla/... на BASE_URL/bla/bla/...

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

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

>> сервиса висит за LDAP авторизацией через nginx
> 
> Вот как раз transmission прекрасно работает с указанием префикса.
> 
> Там единственное, что нужно сделать кроме проксирования
> /transmission/ это перманентный редирект /transmisson
> на /transmission/web.
Ok, посмотрю, как с ним разобраться.
jDownloader работает тоже.
Остаётся GUI к youtube-dl.

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

А от кого вы защищаться собрались?

05.10.2018 19:12, Коротаев Руслан пишет:
> Victor Wagner  пишет:
> 
>> Каналий-посредников можно ограничить ролью канальных провайдеров. И
>> доверять им не данные, а только передачу шифрованных пакетов.
> 
> Если данные зашифрованы, почему бы не доверить им хранение. Главное
> организовать безопасную передачу ключей и параметров доступа.
> 
>> Когда-то давно, примерно с 2001 до 2015 у меня домашняя машина была
>> доступна из интернета. И в случае срабатывания intrusion detection
>> последоватлельность действий была 
>> 1. Отключить сетевой кабель
>> 2. Загрузиться с rescue cd
>> 3. Разбираться.
> 
> Вы же в курсе, что те, у кого есть физический доступ к вашей домашней
> машине могут сделать тоже самое. А что делать тем, кому вы лично дали
> доступ к вашим данным? Ждать пока вы разберетесь, тогда это трудно
> назвать качественным сервисом.
>

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

05.10.2018 16:36, Коротаев Руслан пишет:
> Igor Savluk  пишет:
> 
>> Да разворачивать php просто не охота :)
> 
> PHP разворачивать не нужно если вы будете устанавливать Nextcloud через
> snap-пакет, это такой специальный контейнер придуманный Canonical для
> Ubuntu (для debian он тоже доступен). В snap всё идет в комплекте и PHP,
> и JS, и всё что нужно (в инете много статей про snap).
>  

Блин, я-то думал откуда эта трэш-мода пошла: вместо .deb выкладывать
"self-hosted" приложение в виде бинаря, содержащего всё. Теперь ясно.
Ubuntu. :-|

>> Про minio знаю и пока его и использую. Просто инетесно а почему именно S3
>> для важных данных? Я думал очень важные данные нужно хранить на флешках под
>> подушкой а не у дяди удаленного в облаке.
> 
> А как дать (убрать) безопасный доступ к данным на флешке под подушкой?
> Как безопасно хранить данные на флешке? Если шифровать, то как безопасно
> хранить ключи? Допустим, вы знаете как хранить ключевой материал, а как
> насчет того кому вы даете доступ? Вы уверены, что он придерживается
> таких же стандартов информационной безопасности как и вы? 
> 
> Под подушкой хорошо хранить то, что используете только вы, а если вы
> хотите организовать взаимодействие с другими людьми, без посредников не
> обойтись. Вернее можно обойтись, но сложность организации
> взаимодействия, перекроет все выгоды от использования ваших данных.
> 

Сложность организации (и цена) могут вас устроить, если реализация
угрозы потери данных будет намного дороже.

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

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

05.10.2018 14:39, D. H. пишет:
> On 05/10/18 01:01 AM, artiom wrote:
>> 2. SAMBA - не вариант. Потому что, одна из основных задач - работа с
>> данными через Интернет.
>> 3. С LDAP тоже есть некоторая проблема. Сервер доступен, как plain без
>> шифрования трафика, но только в сети машины. Т.е., я могу к нему
>> обратиться с локалхоста, из докер-контейнеров, но снаружи запросы не
>> приходят.
> 
> vpn решает обе проблемы. все будет везде и по человечески работать.
>

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

Так не разворачивайте. Docker в помощь. Есть Seafile на C, кстати.

05.10.2018 15:50, Igor Savluk пишет:
> Да разворачивать php просто не охота :)
> 
> Про minio знаю и пока его и использую. Просто инетесно а почему именно
> S3 для важных данных? Я думал очень важные данные нужно хранить на
> флешках под подушкой а не у дяди удаленного в облаке.
> 
> On 05/10/2018 13.17, Коротаев Руслан wrote:
>> Igor Savluk  пишет:
>>
>>> А есть подобная вещь но не на PHP?
>>   Я сам использую Minio-сервер [1] для неважных данных (расшарить через
>> веб-итерфейс корзину, дать ссылку на скачивание), так как у него нет
>> управления пользователями. Точнее, оно особо и ненужно это же хранилище.
>> Там есть Pre-Signed URL, просто не все пользователи понимают как это
>> работает. Minio написан на Go
>>
>> Для важных данных рекомендую Amazon S3 с шифрованием на стороне сервера,
>> там для доступа используются политики IAM, их можно сделать очень
>> гибкими.
>>
>> Кстати, если вы будете устанавливать Nextcloud по умолчанию, вам
>> PHP-файлы править не придется, там большинство функций реализовано через
>> веб-интерфейс.
>>
>> [1]: https://blog.kr.pp.ru/post/2017-07-25/
>>
>

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




05.10.2018 13:17, Коротаев Руслан пишет:
> Igor Savluk  пишет:
> 
>> А есть подобная вещь но не на PHP?
>  
> Я сам использую Minio-сервер [1] для неважных данных (расшарить через
> веб-итерфейс корзину, дать ссылку на скачивание), так как у него нет
> управления пользователями. Точнее, оно особо и ненужно это же хранилище.
> Там есть Pre-Signed URL, просто не все пользователи понимают как это
> работает. Minio написан на Go
> 
> Для важных данных рекомендую Amazon S3 с шифрованием на стороне сервера,
> там для доступа используются политики IAM, их можно сделать очень
> гибкими. 
> 
> Кстати, если вы будете устанавливать Nextcloud по умолчанию, вам
> PHP-файлы править не придется, там большинство функций реализовано через
> веб-интерфейс.
> 
> [1]: https://blog.kr.pp.ru/post/2017-07-25/
> 
Всё тоже самое возможно сделать через Nextcloud.
Кстати, у меня он стоит в их официальном docker-контейнере.

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

Вы не поверите. Я читал ещё ту вашу статью, ссылку на которую вы мне
скидывали. И Nextcloud давным-давно стоит, и я им пользуюсь.
Только это не silver bullet, всех задач не решает.

Недавно брат загрузил видосы. Я их посмотреть не могу без скачивания.
Ведь там AVI. Браузер не поддерживает, а "мы не будем включать, потому
что вообще AVI скоро уйдёт".
Вот Emby поддерживает. Но nextcloud хранит всё в каталогах пользователей.
А пользователь может там держать любой трэш и ещё шифрование на клиенте
включить (неизбирательное) и если я натравлю Emby на хранилище
Nextcloud, там будет явно не то, что хочется увидеть.

Кстати, он через свой LDAP у меня и авторизуется.

05.10.2018 12:22, Коротаев Руслан пишет:
> artiom  пишет:
> 
>> Требуется организовать доступ к медиатеке, позволяющий нескольким
>> пользователям переименовывать, удалять и, главное, добавлять файлы.
>>
>> Медиатеку показываю, используя Emby, но с добавлением там всё плохо, а о
>> полноценном управлении, как файловой структурой, и говорить нечего.
>>
>> При этом, условие такого, что пользователи авторизуются через LDAP.
>>
>> Один из вариантов был - использовать файловые менеджеры в
>> докер-контейнере, типа sprut.io, но с LDAP там всё плохо.
>> Ещё один вариант, который я серьёзно рассматривал - использовать sshfs и
>> системный pam-ldap модуль. Но встали вопросы: как не дать пользователю
>> выполнять команды и ограничить просмотр дерева не выше того каталога, в
>> котором хранится медиатека?
>>
>> Есть какие-то варианты того, как эту задачу решают белые люди?
>> Что посоветуете?
>> И по pam-ldap вопросы тоже актуальны.
> 
> Попробуйте Nextcloud [1], легко устанавливается через snap (через докер
> тоже можно), есть LDAP, есть мобильные клиенты, можно даже видео
> смотреть через браузер и музыку слушать.
> 
> [1]: https://ru.wikipedia.org/wiki/Nextcloud
>

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

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

05.10.2018 18:17, Victor Wagner пишет:
> 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: Доступ к медиатеке




05.10.2018 09:23, Victor Wagner пишет:
> On Fri, 5 Oct 2018 09:01:46 +0300
> artiom  wrote:
> 
>> 1.  Windows клиентов пока нет. Но, в идеале, не хотелось бы
>> привязываться к ОС. SSHFS есть почти везде, браузер - ещё лучше.
> 
> sshfs нет почти нигде. В windows нет, в андроиде - нет.
> Насчет MacOS не уверен, надо у коллег поспрашивать. Про экзотику типа
> Solaris я и не говорю.
> 
1. Windows:
https://nelsonslog.wordpress.com/2017/07/19/windows-sshfs-clients/
2. Android: https://4pda.ru/forum/index.php?showtopic=730752
3. Для MacOS есть через аналог FUSE.
4. Solaris не использую. И вообще найти клиент на Solaris сложнее, чем
sshfs под него.

Плюс, есть плагины ко всяким файловым менеджерам, её поддерживающие.

> webdav это не браузер (возможно к сожалению).  То есть браузером в
> лучшем случае получится читать файлы (если кто мне расскажет про плагин
> к файрфоксу, превращающий его в файлменеджер для dav-сайта, буду
> благодарен). А писать - либо davfs2, либо cadaver, либо какой-нибудь
> файлменеджер.
> 
Было такое: https://addons.mozilla.org/ru/firefox/addon/open-as-webfolder/
Но это не то, конечно. Но протокол несложный, возможно написать.

>> 2. SAMBA - не вариант. Потому что, одна из основных задач - работа с
>> данными через Интернет.
> 
> Это как раз то, для чего лично я использую webdav. Для менеджмента
> файлов на сервере, располженном на хостинге. 
> 
Остаётся вопрос, как это поднять.

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

Нашёл пару решений.
Одно на Apache:
https://github.com/MrsKensington/docker-user-webdav-ldap

Второе на nginx:
https://github.com/jtilander/docker-webdav

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

> 
>>
>> Но, похоже, что WebDAV - вполне себе решение, смотрю.
> 
> Крайне рекомендую задуматься над тем, чтобы использовать digest
> authentication. Я правда сходу не понял, как в Apache подружить
> mod_auth_digest и mod_authnz_ldap. А в nginx я вообще не очень
> разбираюсь. Но точно знаю что по крайней мере с basic auth webdav в
> nginx с LDAP работает.
> 
> В перспективе расширения списка клиентских платформ это бы очень
> пригодилось.
> 
Пока я его не поднял, выбирать тип аутентификации рано, да и у меня
обратный прокси, который всё гоняет через HTTPS, так что не столь важно.

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

1.  Windows клиентов пока нет. Но, в идеале, не хотелось бы
привязываться к ОС. SSHFS есть почти везде, браузер - ещё лучше.
2. SAMBA - не вариант. Потому что, одна из основных задач - работа с
данными через Интернет.
3. С LDAP тоже есть некоторая проблема. Сервер доступен, как plain без
шифрования трафика, но только в сети машины. Т.е., я могу к нему
обратиться с локалхоста, из докер-контейнеров, но снаружи запросы не
приходят.

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

05.10.2018 06:52, 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.
> 
> 
>

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

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

В 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.
Как сделать проксирование так, чтобы сервисы обращались по нужному адресу?

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

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

Требуется организовать доступ к медиатеке, позволяющий нескольким
пользователям переименовывать, удалять и, главное, добавлять файлы.

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

При этом, условие такого, что пользователи авторизуются через LDAP.

Один из вариантов был - использовать файловые менеджеры в
докер-контейнере, типа sprut.io, но с LDAP там всё плохо.
Ещё один вариант, который я серьёзно рассматривал - использовать sshfs и
системный pam-ldap модуль. Но встали вопросы: как не дать пользователю
выполнять команды и ограничить просмотр дерева не выше того каталога, в
котором хранится медиатека?

Есть какие-то варианты того, как эту задачу решают белые люди?
Что посоветуете?
И по pam-ldap вопросы тоже актуальны.

Re: Файлы

Теперь ясно. Спасибо.

> В 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 никого не волнует.
>

Re: Файлы

ЫЫЫ: "Subordinate user/group ids appear in Linux kernel 3.12 in 2013."

Что это я понял. Но для чего это не вполне понятно не только после
прочтения man, но и после прочтения док, даже то, что "для LXC" не
сильно прояснило ситуацию.
Русским языком можете объяснить, зачем эта штука появилась?

26.08.2018 16:11, Иван Лох пишет:
> On Sun, Aug 26, 2018 at 01:47:18PM +0300, artiom wrote:
>> И ещё, чей файл /etc/machine-id?
> 
>> Туда же: что такое /etc/subgid и /etc/subuid?
> 
> RTFM
> 
> man subuid
> dpkg -S subuid
>

Re: Файлы

Спасибо.

А {passwd,group}.org соображения есть?

26.08.2018 16:11, Иван Лох пишет:
> On Sun, Aug 26, 2018 at 01:47:18PM +0300, artiom wrote:
>> И ещё, чей файл /etc/machine-id?
> 
>> Туда же: что такое /etc/subgid и /etc/subuid?
> 
> RTFM
> 
> man subuid
> dpkg -S subuid
>

Re: Файлы