Re: Gnus, поиск по содержимому сообщений

[Dmitry Alexandrov]

> Вт, 30 авг 2016, 02:00, Dmitry Alexandrov:
>
 Если речь о Гнусе, то уверенно искать по группе при помощи M-s / M-r
 все-таки нельзя, ибо это поиск по *исходному* (а не декодированному)
 тексту письма, который может быть вовсе и не текстом.
>>>
>>> Это не так. Извините за каламбур, но поищите в рассылке, здесь недавно
>>> обсуждалось.
>>
>> Пардон, что значит «не так», когда легко убедиться, что по крайней мере
>> из коробки все именно так?  Вот, к примеру, т. Дмитрий Кашин посылает в
>> эту рассылку письма обернутыми в base64, значит, чтоб найти в них слово,
>> скажем, «Systemd» посредством M-s в Гнусе нужно запросить его не иначе,
>> чем как «U3lzdGVtZ», по «Systemd» же вы ничего так не найдете.
>>
>> Гнус (и ГНУ Емакс вообще) у меня вроде бы самый что ни на есть
>> последний, так что остается только, что я упустил какую-то опцию, что
>> надо включить.  Может быть, вы подскажете, какую?
>
> «Не так» — значит, что поиск может работать по декодированному тексту.
> Видимо, судя по вашим наблюдениям, он может работать и по кодированному,

Дело не в том, что он «может».  А в том, что именно так — по
нераскодированному тексту — он работает из коробки.  О чем, собственно,
и в документации сказано:

,[ (info "(gnus) Searching for Articles") ]
| ‘M-s’
|  Search through all subsequent (raw) articles for a regexp
|  (‘gnus-summary-search-article-forward’).
`

> но я не знаю (или не помню), как добиться такого поведения.

Жаль.  Если когда-нибудь случайно вспомните, буду рад, если сообщите.

> Попробуйте разобраться, если это действительно важно.

Да спасибо, не очень.  Я, повторюсь, предпочитаю индексацию
полнотекстовому поиску.

Re: [DONE] wml://security/2016/dsa-365{2,3,4}.wml

[Vladimir Zhbanov]

On Fri, Aug 26, 2016 at 10:35:43AM +0500, Lev Lamberov wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> - --- english/security/2016/dsa-3652.wml  2016-08-26 09:55:55.0 
> +0500
> +++ russian/security/2016/dsa-3652.wml2016-08-26 10:12:34.802247273 
> +0500
> @@ -1,17 +1,18 @@
> - -security update
> +#use wml::debian::translation-check translation="1.1" maintainer="Lev 
> Lamberov"
> +обновление безопасности
>  
> - -This updates fixes many vulnerabilities in imagemagick: Various memory
> - -handling problems and cases of missing or incomplete input sanitising
> - -may result in denial of service or the execution of arbitrary code if
> - -malformed TIFF, WPG, RLE, RAW, PSD, Sun, PICT, VIFF, HDR, Meta, Quantum,
> - -PDB, DDS, DCM, EXIF, RGF or BMP files are processed.
> +В данном обновлении исправлены многие уязвимости в imagemagick: различные 
> проблемы
> +работы с памятью, случаи отсутствующей или неполной очистки входных
> +данных могут приводить к отказу в обслуживании или выполнению произвольного 
> кода при
> +обработке некорректных файлов в форматах TIFF, WPG, RLE, RAW, PSD, Sun, 
> PICT, VIFF, HDR, Meta, Quantum,
> +PDB, DDS, DCM, EXIF, RGF или BMP.
>  
> - -For the stable distribution (jessie), these problems have been fixed in
> - -version 8:6.8.9.9-5+deb8u4.
> +В стабильном выпуске (jessie) эти проблемы были исправлены в
> +версии 8:6.8.9.9-5+deb8u4.
>  
> - -For the unstable distribution (sid), these problems will be fixed 
> soon.
> +В нестабильном выпуске (sid) эти проблемы будут исправлены позже.
>  
> - -We recommend that you upgrade your imagemagick packages.
> +Рекомендуется обновить пакеты imagemagick.
>  
>  
>  # do not modify the following line
> - --- english/security/2016/dsa-3653.wml  2016-08-26 09:56:14.0 
> +0500
> +++ russian/security/2016/dsa-3653.wml2016-08-26 10:32:04.876919896 
> +0500
> @@ -1,24 +1,25 @@
> - -security update
> +#use wml::debian::translation-check translation="1.1" maintainer="Lev 
> Lamberov"
> +обновление безопасности
>  
> - -Alexander Sulfrian discovered a buffer overflow in the
> - -yy_get_next_buffer() function generated by Flex, which may result in
> - -denial of service and potentially the execution of code if operating on
> - -data from untrusted sources.
> +Александр Сулфриан обнаружил переполнение буфера в функции
> +yy_get_next_buffer(), порождаемой Flex, которое может приводить к
> +отказу в обслуживании и потенциальному выполнению кода в случае работы
> +с данными из недоверенных источников.
>  
> - -Affected applications need to be rebuild. bogofilter will be rebuild
> - -against the updated flex in a followup update. Further affected
> - -applications should be reported at the bug referenced above.
> +Приложения, затронутые данной уязвимостью, следует собрать заново. Пакет 
> bogofilter будет
> +заново собран в соответствии с обновлённым пакетом flex при последующем 
> обновлении. Следует
> +сообщить о других приложения, затрагиваемых этой проблемой, в сообщение об 
> ошибке, указанное вверху.

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

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

>  
> - -For the stable distribution (jessie), this problem has been fixed in
> - -version 2.5.39-8+deb8u1.
> +В стабильном выпуске (jessie) эта проблема была исправлена в
> +версии 2.5.39-8+deb8u1.
>  
> - -For the testing distribution (stretch), this problem has been fixed
> - -in version 2.6.1-1.
> +В тестируемом выпуске (stretch) эта проблема была исправлена
> +в версии 2.6.1-1.
>  
> - -For the unstable distribution (sid), this problem has been fixed in
> - -version 2.6.1-1.
> +В нестабильном выпуске (sid) эта проблема была исправлена в
> +версии 2.6.1-1.
>  
> - -We recommend that you upgrade your flex packages.
> +Рекомендуется обновить пакеты flex.
>  
>  
>  # do not modify the following line
> - --- english/security/2016/dsa-3654.wml  2016-08-26 09:56:30.0 
> +0500
> +++ russian/security/2016/dsa-3654.wml2016-08-26 10:35:34.793093405 
> +0500
> @@ -1,27 +1,28 @@
> - -security update
> +#use wml::debian::translation-check translation="1.1" maintainer="Lev 
> Lamberov"
> +обновление безопасности
>  
> - -Two vulnerabilities were discovered in quagga, a BGP/OSPF/RIP routing
> - -daemon.
> +В quagga, службе маршрутизации BGP/OSPF/RIP, были обнаружены две
> +уязвимости.
>  
>  
>  
> href="https://security-tracker.debian.org/tracker/CVE-2016-4036;>CVE-2016-4036
>  
> - - Tamás Németh discovered that sensitive configuration files in
> - - /etc/quagga were world-readable despite containing sensitive
> - - information.
> + Тамас Немет обнаружил, что чувствительные файлы настройки в
> + /etc/quagga открыты для чтения всем пользователям, хотя и содержат 
> чувствительную
> + информацию.
>  
> 

Re: проблема с выходом из спящего режима

[Sohin Vyacheslav]

29.08.2016 20:34, Tim Sattarov пишет:
> У меня похожее было, оказывалось, что экран тупо затемнён, увеличение
> яркости помогало.
> Попробуй в следующий раз, может поможет ?

не помогло увеличение яркости...

-- 
BW
Сохин Вячеслав

Re: [debian-devel] Обсуждение удаления sysvinit-скриптов из пакетов.

[Victor Wagner]

On Tue, 30 Aug 2016 15:18:52 +0500
Stanislav Vlasov  wrote:

> 30 августа 2016 г., 13:26 пользователь Victor Wagner
>  написал:
> 
> >> > Для конкретного случая можно специфицировать некое подмножество
> >> > этого протокола.
> >> > Например, вызов с параметрами start/stop/restart.  
> >> Если этот вызов для админа, а не для загрузки - не вижу проблем.  
> >
> > Тут вопрос скорее в интерфейсе для мейнтейнера пакета, а не админа
> > или  
> 
> Судя по первому сообщению темы, мейнтейнер вообще хочет писать только
> под systemd, потому это дело либо админа, либо дополнений к системе
> инициализации.

Мейнтейнер сейчас вынужден оглядываться на существующую реальность.
Большая часть дистрибутивов использует systemd.

Поэтому в первом же письме я предлагал воспольноваться тактикой embrace
and extend - для нашего, правильного интерфейса сделать переходник
(интерпретатор), который позволит ему использовать service-файлы от
systemd.

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

Для sysvinit это просто - нужно только insserv подправить что  при
генерации зависимостей умел не только читать LSB-style комментарии, но
и вызывать скрипт согласно протоколу.  Вернее скорее всего в обратном
порядке - сначала позвать с параметром depends, если выругалось что
такого параметра не знает, попробовать почитать, вдруг там LSB-style
комментарии.

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

Re: [debian-devel] Обсуждение удаления sysvinit-скриптов из пакетов.

[Victor Wagner]

On Tue, 30 Aug 2016 12:03:52 +0300
Dmitrii Kashin  wrote:

> Victor Wagner  writes:
> 
> > On Tue, 30 Aug 2016 10:29:53 +0500
> > Stanislav Vlasov  wrote:
> >  
> >>   

> > А уже потом, специфицировав этот протокол, делаем интерпретаторы для
> > существующих декларативных конифгов и врапперы для прочих случаев,
> > поддерживающие этот протокол.  
> 
> Я тут хотел бы также вклиниться, ибо уже не раз встречал что-то
> подобное. Важно, чтобы этот интерфейс был на интерпретируемом языке. Я
> слышал, что раньше было можно вместо init-скрипта подставить просто
> бинарный файл, поддерживал бы он только необходимый набор аргументов
> типа start/stop/etc... Имхо это конечно возможность интересная, но для
> системного администратора совершенно негодно, ибо одно дело -
> переписать скрипт на живой системе, и совсем другое - пересобрать
> бинарь, выполняющий ту же функцию.

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

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

Собственно, на самом деле sysvinit начал проигрывать тогда, когда
в среднем внутри оказалось аж три уровня врапперов - 
сначала start-stop-daemon запускает собственно бинарь,
потом start-stop-daemon мы оборачиваем в стандартные функции
из /lib/init/functions, а потом уже из этих функций собираем
стандартный скрипт.

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

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

А вот сделать обертку, которая вызывается с параметрами
start/stop/depends/reload и сама вызывает бинарник с теми же
параметрами, выполняя на каждый из них какие-то предварительные (или
наоборот) действия - это несложно.


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

Принуждать - нехорошо. А симлинк в /etc/init.d на файлик из /usr/sbin -
хорошо. Для тех 95% админов, которым не нужно от демона странного, а
нужно стандартное поведение.

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

Re: [debian-devel] Обсуждение удаления sysvinit-скриптов из пакетов.

[Stanislav Vlasov]

30 августа 2016 г., 13:26 пользователь Victor Wagner
 написал:

>> > Для конкретного случая можно специфицировать некое подмножество
>> > этого протокола.
>> > Например, вызов с параметрами start/stop/restart.
>> Если этот вызов для админа, а не для загрузки - не вижу проблем.
>
> Тут вопрос скорее в интерфейсе для мейнтейнера пакета, а не админа или

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

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

Для sysvinit я подобное ещё представляю. С другими init могут быть проблемы.

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

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

Хм... Сложный вопрос, так как у системы инициализации может просто не
быть такого интерфейса в удобном виде.
Просто набор сервисов, которые требуется запустить в любом порядке +
внутри запускаемого конфига сервиса - команда на запуск зависимостей
из других сервисов.
При этом оно _не_ совместимо с тем, что обычно лежит в /etc/init.d и
может не предоставлять совместимый интерфейс в данном каталоге, а если
и предоставляет, то не использует это внутри себя.

-- 
Stanislav

Re: [debian-devel] Обсуждение удаления sysvinit-скриптов из пакетов.

[Dmitrii Kashin]

Victor Wagner  writes:

> On Tue, 30 Aug 2016 10:29:53 +0500
> Stanislav Vlasov  wrote:
>
>> 
>> > Для конкретного случая можно специфицировать некое подмножество
>> > этого протокола.  
>> 
>> > Например, вызов с параметрами start/stop/restart.  
>> 
>> Если этот вызов для админа, а не для загрузки - не вижу проблем.
>
> Тут вопрос скорее в интерфейсе для мейнтейнера пакета, а не админа или
> системы инициализации. В смысле, если предоставишь исполняемый
> файл с вот таким интерфейсом - при вызове с параметром start делает то,
> stop се, depends это, то система инициализации этот файл подхватит и
> будет через него демоном управлять.
>
> А уже потом, специфицировав этот протокол, делаем интерпретаторы для
> существующих декларативных конифгов и врапперы для прочих случаев,
> поддерживающие этот протокол.

Я тут хотел бы также вклиниться, ибо уже не раз встречал что-то
подобное. Важно, чтобы этот интерфейс был на интерпретируемом языке. Я
слышал, что раньше было можно вместо init-скрипта подставить просто
бинарный файл, поддерживал бы он только необходимый набор аргументов
типа start/stop/etc... Имхо это конечно возможность интересная, но для
системного администратора совершенно негодно, ибо одно дело - переписать
скрипт на живой системе, и совсем другое - пересобрать бинарь,
выполняющий ту же функцию.

В этом плане я, по-видимому, являюсь сторонником LSB-заголовков в sysvinit,
поскольку они принуждают мейнтейнера использовать скриптовые запускалки.




signature.asc
Description: PGP signature

Gnus, поиск по содержимому сообщений (was: Gmane потихоньку умирает...)

[Dmitry Derjavin]

Вт, 30 авг 2016, 02:00, Dmitry Alexandrov:

>>> Если речь о Гнусе, то уверенно искать по группе при помощи M-s / M-r
>>> все-таки нельзя, ибо это поиск по *исходному* (а не декодированному)
>>> тексту письма, который может быть вовсе и не текстом.
>>
>> Это не так. Извините за каламбур, но поищите в рассылке, здесь недавно
>> обсуждалось.
>
> Пардон, что значит «не так»[…]

«Не так» — значит, что поиск может работать по декодированному тексту.
Видимо, судя по вашим наблюдениям, он может работать и по кодированному,
но я не знаю (или не помню), как добиться такого поведения. Попробуйте
разобраться, если это действительно важно.

> (По рассыке, разумеется, поискал — по словам «Gnus» и «Гнус» — ничего
> похожего.)

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

-- 
~dd

Re: [debian-devel] Обсуждение удаления sysvinit-скриптов из пакетов.

[dimas]

2016-243 11:26 Victor Wagner  wrote:
> Тут вопрос скорее в интерфейсе для мейнтейнера пакета, а не админа или
> системы инициализации. В смысле, если предоставишь исполняемый
> файл с вот таким интерфейсом - при вызове с параметром start делает то,
> stop се, depends это, то система инициализации этот файл подхватит и
> будет через него демоном управлять.
> 
> А уже потом, специфицировав этот протокол, делаем интерпретаторы для
> существующих декларативных конифгов и врапперы для прочих случаев,
> поддерживающие этот протокол.
это все хорошо, пока демон запускается/останавливается на уровне простейших
действий: запустить указанный бинарник, пид-файл покласть туда-то, уйти в фон и
не отсвечивать. такому можно и /etc/init.d/skeleton подсунуть, указав только,
кого и откуда запущать.
и как раз такие случаи приводили в пример свидетили шыштемдэ, когда кричали,
что вот, у нас все запускается через простые текстовые "юниты" без всяких там
шелл-скриптов. но как только появляются какие-то другие действия при загрузке -
создать какую-то помойку, убрать за собой при запуске, запустить еще какие-то
вспомогательные сервисы, etc - вернулись к тому же, что с такой помпой
"закапывали" - к шелл-скриптам))
а еще в /etc/init.d полно всякой фигни, которая не является демонами как
таковыми, но вполне себе Provides, Depends и прочия - всякие там mount*,
checkroot и иже с ними. там чистая шелл-лапша, куда без нее. или что с ними
делать? переписывать на сях, чтоб был непременно бинарник? запихивать все в
общую помойку системы инициализации? и если что-то там понадобится подправить,
то пересобирать-перекомпилять?
я не в курсе, как там в шыштемдэ реализованы все эти fsck и прочее - запихано в
и без того жЫрный pid 1? и как это унифицировать без "шелл-лапши" - тоже не
очень представляю...

Re: [debian-devel] Обсуждение удаления sysvinit-скриптов из пакетов.

[Victor Wagner]

On Tue, 30 Aug 2016 10:29:53 +0500
Stanislav Vlasov  wrote:

> 
> > Для конкретного случая можно специфицировать некое подмножество
> > этого протокола.  
> 
> > Например, вызов с параметрами start/stop/restart.  
> 
> Если этот вызов для админа, а не для загрузки - не вижу проблем.

Тут вопрос скорее в интерфейсе для мейнтейнера пакета, а не админа или
системы инициализации. В смысле, если предоставишь исполняемый
файл с вот таким интерфейсом - при вызове с параметром start делает то,
stop се, depends это, то система инициализации этот файл подхватит и
будет через него демоном управлять.

А уже потом, специфицировав этот протокол, делаем интерпретаторы для
существующих декларативных конифгов и врапперы для прочих случаев,
поддерживающие этот протокол.


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

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


> 
> > Вообще этот вопрос у меня в ЖЖ примерно два года назад уже
> > обсуждался.
> >
> > http://vitus-wagner.livejournal.com/1032172.html  
> 
> Видел, но там, помнится, до чего-то конкретного не дошло, только
> обсуждения преимуществ/недостатков разных подходов инитов.
> 

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