Re: libsqlite3-dev - error
Как правильно задавать вопросы https://sitengine.ru//smart-question-ru.html 26.06.2024 08:46, Serge Shu пишет: Rus error: libsqlite3-dev : Зависит: libsqlite3-0 (= 3.40.1-2) но 3.42.0-1 должен быть установлен Eng error (google translate): libsqlite3-dev : Depends: libsqlite3-0 (= 3.40.1-2) but 3.42.0-1 must be installed
Re: LDAP
20.04.2018 12:44, artiom пишет: Так это, господа гуру криптографии и распределения ключей, FAQ-то пользоваться или неактуально? easy-rsa уже отменяется, я так понял? Свой CA во вменяемом виде сейчас хрен поднимешь? кто-то в рассылке советовал tinyca на яве и nanoca (или picoca?) - консольный. Первый есть в stretch, есть ещё какой-то pica: apt-cache search "Certification Authority" gnomint - X.509 Certification Authority management tool for GNOME pyca - Certification Authority written in Python tinyca - simple graphical program for certification authority management
Re: L2TP over IPSec
On 30.08.2017 00:24, Artem Chuprina wrote: Судя по тому, что я вижу, до pppd дело не доходит. Ругань вываливается быстро, т.е. с того конца, видимо, не глухо, а refused. Покажите вывод ip xfrm state ip xfrm policy Хотелось бы разобраться, что за фигня, но читать протокольные пакеты глазами, особенно если они шифруются, ресурса нет. Может, я тупо что-то известное не вписал или вписал не так? Разница в tcpdump host x.y.z.t на роутере когда подключатся windows и когда подключается linux тоже может дать пищу для размышлений.
Re: NAS
On 07.07.2017 02:43, Sergey Matveev wrote: *** artiom [2017-07-06 22:39]: Кстати, наткнулся вот на такой коммент: https://www.linux.org.ru/forum/linux-hardware/7293310#comment-7294806 Комментарий правильный. В большинстве случаев достаточен программный RAID. "Умность" жёстких дисков действительно только вредит и, если есть возможность отключать write cache, то однозначно надо. Под ZFS Вы отключаете кэш на дисках? Или это в контексте аппаратного рэйда? А насчёт комментария по ссылке, то вывод - правильный, но с этим категорически не согласен(имхо, фантазия в чистом виде): Ну вообще насчёт ненадёжности он прав... Из за хитрых алгоритмов кеширования в самих винтах+ncq запись происходит несинхронно и мдрайд в фоне потхонечку зеркала выравнивает потом. ^ mdraid выравнивает зеркала??? Интеллект винтов здесь во вред идёт. Поскольку ОЗУ у тебя батарейкой не подпёрто, в отличие от кеша апаратного райда, в случае жёсткого виса системы (не пропадания питания, это можно решить бесперебойником, а именно виса, например по вине иксов\видеокарты\взорвавшегося кондёра на маме\етс) получишь две по разному испорченные половины. Ну а это - аварийная ситуация в чистом виде - кондёр может взорваться и на raid-контроллере. PS Что бы два раза не вставать - Сергей, спасибо за ваши посты по zfs. Вам стоит их причесать в статью и опубликовать - прослыть евангелистом zfs ;-)
Re: NAS
On 12.07.2017 14:41, Stanislav Vlasov wrote: 12 июля 2017 г., 11:03 пользователь Andrey A Lyubimets написал: А на самом деле - даже простенький железный рейд с своим кешом и батарейкой даст прикурить софтовому рейду. HP Smart Array P410 достаточно простенький, чтоб всё ещё считаться железным рейдом? А то raid6 из 8 с ним давал порядка 100 МБ/сек при наличии батарейки, а raid6 mdadm на тех же дисках в том же сервере - порядка 400 МБ/сек. А отдельные диски получали как 8 RAID0 или переводили P410 в HBA режим? Как 8 RAID0 Может тут кумулятивный эффект - более мощный ЦПУ для raid6 + кэш контроллера?
Re: NAS
On 07.07.2017 12:39, Stanislav Vlasov wrote: 7 июля 2017 г., 3:40 пользователь Andrey Jr. Melnikov написал: А на самом деле - даже простенький железный рейд с своим кешом и батарейкой даст прикурить софтовому рейду. HP Smart Array P410 достаточно простенький, чтоб всё ещё считаться железным рейдом? А то raid6 из 8 с ним давал порядка 100 МБ/сек при наличии батарейки, а raid6 mdadm на тех же дисках в том же сервере - порядка 400 МБ/сек. А отдельные диски получали как 8 RAID0 или переводили P410 в HBA режим?
Re: создание своего пакета под несколько версий операционок
On 29.03.2017 17:39, Victor Wagner wrote: On Wed, 29 Mar 2017 15:29:08 +0700 Andrey Lyubimets wrote: Навеяно параллельным тредом. Нужно собирать пакет для для двух версий debian и для четырех версий ubuntu, да для двух архитектур (пока ?) pbuilder + reprepro спасёт отца русской демократии ? Спасет. Но нужно понимать что нужна какая-то основная архитектура, на которой будешь патчить исходники, выполнять большую часть отладки и т.д. А потом пересобирать для остальных. Когда я себе выстраивал подобную систему у меня сборка была разделена на два этапа: 1. Собираем на архитектуре и релизе, совпадающими с хост-системой (все равно в pbuilder, чтобы не загрязнять систему dev-пакетами). 2. Если там все получилось - запускаем пересборку только архитектурно-зависимых пакетов на всем остальном многообразии. С поддержкой разных релизов еще рекомендуется задуматься над поддержкой версионирования. Чтобы потом у юзера при дистапгрейде пакет, собранный под предыдущий релиз (с соответсвующими зависимостями от библиотек) не зависал. Проблему понимаю, но решение - не очень. Добавление суффикса, как советует Andrey Jr. Melnikov в соседнем письме достаточно для этого? То есть у меня получалось так, что последняя запись в changelog-е генерируется автоматическии и выглядит как "rebuild for release".
Re: аналоги spamassasin
On 14.07.2015 22:28, Andrey Tataranovich wrote: On Tue, 14 Jul 2015 17:31:01 +0300 Victor Wagner wrote: Внешние проверки spamassassin тоже умеет. Но я остерегаюсь им давать большие веса. Не доверяю я им всем вместе взятым и каждому в отдельности. Попасть в их черные списки просто (сам не раз попадал) а вычиститься - сложно. Отшибать письма на основе rbl при smtp сессии - зло, но использовать rbl для добавления веса в SA - нормальная практика. а можно не отшибать,но направить на грейлистинг Greylisting не всегда удобен, особенно если есть несколько MX. Да и считается он невежливым поведением. ИМХО,грейлистинг часто неправильно применяют. Грейлистинг здорово защищает от спама с завирусованных виндов, но бессилен, если спамер поднимает полнофункциональный мта. Поэтому, если на простых проверках (HELO, spf, обратная днс-запись для клиента и тп) появились сомнения в легитимности клиента, то только тогда отправляю на грейлистинг. Razor, pyzor, dcc основаны на хешировании писем и насколько я знаю туда может попасть конкретное письмо, а не отправитель или сервер. Если сработали одновременно хотя бы два внешних чека (PYZOR_CHECK, RAZOR_CHECK, DCC_CHECK), то 99.99% что это спам. По крайнем мере мне никто еще не показал false positive по этим фильтрам. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55c19e47.9040...@nskes.ru
Re: Хочется странного - не только второй MX, но и IMAP
On 28.01.2015 10:10, Дмитрий Подковыркин wrote: Спасибо, в основном всё понятно. Самым простым решением будет хранение писем в реплицируемой sql базе, наличие двух полностью настроенных smtp и imap серверов (можно и sql на них держать) и и самый простой способ получить кучу проблем (имхо не только моё -- http://deflexion.com/2006/06/for-imap-sql-just-sucks ) Лучше потратьте эту энергию на борьбу с падениями сервера. перевод трафика с помощью dns на slave сервер при падении primary. 25 января 2015 г. 8:12:11 GMT+05:00, Artem Chuprina пишет: Dmitry Podkovyrkin -> debian-russian@lists.debian.org @ Sat, 24 Jan 2015 18:44:17 +0500: DP> Здравствуйте. DP> Подскажите как реализовать или где почитать о таком: DP> Есть два сервера, на одном из них Postfix и Dovecot-IMAP, он первичный MX DP> На втором только Postfix - он вторичный MX. DP> Теперь при отказе одного из серверов входящая почта никуда не денется, но DP> хочется пользоваться и хранимой почтой и отправлять почту как обычно. То есть DP> требуется синхронизировать пользовательские ящики IMAP и каком-то образом DP> переключать у пользователей в почтовом клиенте imap и smtp серверы. DP> То есть вопроса два: DP> 1. Как синхронизировать хранилище IMAP между двумя серверами так, чтоб DP>можно было быть уверенным в актуальности данных? К сожалению, имеющийся опыт синхронизации IMAP показывает, что доступные решения редкостно ненадежны. Для работы в полном автопилоте не годятся. Разве что работа на реплицируемой в обе стороны базе, причем именно на базе, а не на maildir'ах. DP> 2. Какие средства использовать для переключения пользовательских DP>программ (Thunderbird, etc) на запасной imap и smtp сервер? Записи в DP>DNS с коротким временем жизни? В этом варианте - да. DP> Да, и еще один вопрос. Сейчас вторичный MX настроен только на прием и DP> пересылку всех писем на первичный MX. Если Primary MX падает, то его роль DP> должен взять на себя вторичный. Замена конфига и перезапуск? Да. Причем, возможно, вторичник вообще не стоит держать в режиме вторичника. Т.е. либо не отвечает вообще (если первичник жив), либо взял на себя его роль. -- Подковыркин Дмитрий email: d...@ddipp.net skype: dmitryrw -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54c8c299.4090...@nskes.ru
Re: Отечественная криптография
On 21.01.2015 20:22, Max Dmitrichenko wrote: 21 января 2015 г., 15:54 пользователь Victor Wagner написал: On Wed, 21 Jan 2015 14:46:06 +0300 Max Dmitrichenko wrote: Вот отличная статья с храбра http://habrahabr.ru/post/248269/ на тему использования каких-нибудь сертифицированных реализаций. Интересно, а на сколько ключи ГОСТа подвержены таким закладкам? Там не столько про "использование сертифицированных реализаций" сколько про "не доверяйте сторонним организациям генерировать вам ключи". Нет, не совсем. Я могу генирировать их и у себя на компе. Но если это делается закрытой софтиной, то будь она хоть трижды сертифицирована, а её разработчик крещён, то бей в зеленый барабан. Собственно, генерируя закрытой софтиной, ты доверяешь её автору генерацию ключей. Впрочем, удостоверяющему центру доверять как раз можно - никто не помешает ему сгенерировать свою собственную ключевую пару и выписать на неё сертификат на ваше имя. Это тоже не совсем так. Когда я получаю сертификат в УЦ, то расписываюсь в его получении. Эта подпись и есть связующее звено между реальным бумажным и цифровым миром. увы, твоя подпись ничем подобным не является То что у ГОСТ 28147 существуют более и менее криптостойкие наборы параметров - это факт. Но вот те параметры, которые приведены в RFC 4357 используются уже много лет и пока никто не взломал. Возможно, что и не взломают. Но поговаривают, что если знать, как они были выбараны, то может открыться и тайная дверь. В этом случае и в ключ закладку ставить не придется ). -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54c09922.7080...@nskes.ru
