Re: [systemd] [suspend] [перфекционизм] А какой сейчас документированный способ передергивания беспроводных адаптеров при спячке?

2017-03-28 Пенетрантность Dmitry Alexandrov 
>> Как известно, многие беспроводные сетевые карты с несвободными
>> прошивками (да и не только они) плохо совместимы с погружением машины
>> спячку того или иного вида (suspending / hibernation).
>> 
>> Есть и традиционный костыль, решающий эту проблему, — выгрузка-
>> загрузка линуксового модуля, отвечающего за таковое устройство.
>> 
>> До прихода systemd в Дебиане был предусмотрен и описан в pm-action(8) 
>> интерфейс для настройки костыля: куда-нибудь в /etc/pm/config.d/
>> можно было прописать, к примеру, SUSPEND_MODULES="r8712u".
>> 
>> А что теперь?  Нет, мне, разумеется, не сложно написать два .service-
>> файла и кинуть их в /etc/systemd/system/:
>>
>> ...
>>
>> Но какого-нибудь более пользовательского, документированного решения
>> ныне в Дебиане из коробки не предусмотрено?
>
> Я сделал так. Этот скрипт повесил на systemd и горя с sleep и hibernate
> не имею. http://codepad.org/BH0HDxXC

Э... Вы, кажется, ссылку перепутали.  (И вообще — какие ссылки — мы же не в 
IRC!)  Там следующее:



raw.rb
Description: application/ruby

Это, насколько я понял, костыль для отключения пробуждения из энергозависимой 
спячки (suspending) по сигналу с ряда устройств.  Там, кстати, написано «from 
hibernate or sleep», но я не могу представить себе, как это может повлиять на 
способы *включения* машины; если ошибаюсь — поправьте.

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

,[ /etc/udev/rules.d/43-disable-wakeup-on-peripherals.rules ]
| ACTION=="add", TEST=="power/wakeup", ATTR{power/wakeup}="disabled"
`

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


А от вас я жду того кода, который вы хотели привести.  :-)

Re: [systemd] [suspend] [перфекционизм] А какой сейчас документированный способ передергивания беспроводных адаптеров при спячке?

2017-03-28 Пенетрантность Igor Savlook 
On Tue, 2017-03-28 at 23:49 +0300, Dmitry Alexandrov wrote:
> Добрых суток уважаемой рассылке.
> 
> Как известно, многие беспроводные сетевые карты с несвободными
> прошивками (да и не только они) плохо совместимы с погружением машины
> спячку того или иного вида (suspending / hibernation).
> 
> Есть и традиционный костыль, решающий эту проблему, — выгрузка-
> загрузка линуксового модуля, отвечающего за таковое устройство.
> 
> До прихода systemd в Дебиане был предусмотрен и описан в pm-action(8) 
> интерфейс для настройки костыля: куда-нибудь в /etc/pm/config.d/
> можно было прописать, к примеру, SUSPEND_MODULES="r8712u".
> 
> А что теперь?  Нет, мне, разумеется, не сложно написать два .service-
> файла и кинуть их в /etc/systemd/system/:
> 
> ,
> > [Unit]
> > Before=hibernate.target suspend.target hybrid-sleep.target
> > 
> > [Service]
> > Type=oneshot
> > ExecStart=/sbin/modprobe -r r8712u
> > 
> > [Install]
> > WantedBy=hibernate.target suspend.target hybrid-sleep.target
> 
> `
> 
> ,
> > [Unit]
> > After=hibernate.target suspend.target hybrid-sleep.target
> > 
> > [Service]
> > Type=oneshot
> > ExecStart=/sbin/modprobe r8712u
> > 
> > [Install]
> > WantedBy=hibernate.target suspend.target hybrid-sleep.target
> 
> `
> 
> Но какого-нибудь более пользовательского, документированного решения
> ныне в Дебиане из коробки не предусмотрено?

Ну и вроде как незабываем про rfkill.

Re: [systemd] [suspend] [перфекционизм] А какой сейчас документированный способ передергивания беспроводных адаптеров при спячке?

2017-03-28 Пенетрантность Igor Savlook 
On Tue, 2017-03-28 at 23:49 +0300, Dmitry Alexandrov wrote:
> Добрых суток уважаемой рассылке.
> 
> Как известно, многие беспроводные сетевые карты с несвободными
> прошивками (да и не только они) плохо совместимы с погружением машины
> спячку того или иного вида (suspending / hibernation).
> 
> Есть и традиционный костыль, решающий эту проблему, — выгрузка-
> загрузка линуксового модуля, отвечающего за таковое устройство.
> 
> До прихода systemd в Дебиане был предусмотрен и описан в pm-action(8) 
> интерфейс для настройки костыля: куда-нибудь в /etc/pm/config.d/
> можно было прописать, к примеру, SUSPEND_MODULES="r8712u".
> 
> А что теперь?  Нет, мне, разумеется, не сложно написать два .service-
> файла и кинуть их в /etc/systemd/system/:
> 
> ,
> > [Unit]
> > Before=hibernate.target suspend.target hybrid-sleep.target
> > 
> > [Service]
> > Type=oneshot
> > ExecStart=/sbin/modprobe -r r8712u
> > 
> > [Install]
> > WantedBy=hibernate.target suspend.target hybrid-sleep.target
> 
> `
> 
> ,
> > [Unit]
> > After=hibernate.target suspend.target hybrid-sleep.target
> > 
> > [Service]
> > Type=oneshot
> > ExecStart=/sbin/modprobe r8712u
> > 
> > [Install]
> > WantedBy=hibernate.target suspend.target hybrid-sleep.target
> 
> `
> 
> Но какого-нибудь более пользовательского, документированного решения
> ныне в Дебиане из коробки не предусмотрено?

Я сделал так. Этот скрипт повесил на systemd и горя с sleep и hibernate
 не имею. http://codepad.org/BH0HDxXC

Re: transmission-daemon и постоянные обращения к диску

2017-03-28 Пенетрантность Tim Sattarov 


On 28/03/17 05:17 PM, dimas wrote:
> однако же, поигрался тут еще по-всякому и нашел вот какую вещь: если запустить
> strace -p 5363,5364,5365,5385 -c &> stats
Проще нужно быть :)
strace -p `pidof  transmission-daemon` -f -o stats
> ну и так далее, каждую секунду он зовется и успешно синкает бедный диск. [1]
fsync вызывается толко на один filehandle. если он пуст то синкать
нечего и ничего не пишется.
Это как я понимаю fsync


Сейчас ещё раз посморел на вывод strace:

~# strace  -f  -p `pidof transmission-daemon`  2>&1 | grep fsync
[pid  1831] fsync(2)= -1 EINVAL (Invalid argument)
[pid  1831] fsync(2)= -1 EINVAL (Invalid argument)
[pid  1831] fsync(2)= -1 EINVAL (Invalid argument)
[pid  1831] fsync(2)= -1 EINVAL (Invalid argument)
[pid  1831] fsync(2)= -1 EINVAL (Invalid argument)
[pid  1831] fsync(2)= -1 EINVAL (Invalid argument)
^C


~# file /proc/1831/fd/2
/proc/1831/fd/2: broken symbolic link to socket:[27432]

lsof указывает на unix socket:

transmiss 1831 debian-transmission2u unix
0x9fe1d7728c00  0t0   27432 type=STREAM

то есть у меня обработкой вывода занимается systemd и мне пофиг, fsync
на unix socket  не работает.
однозначно бага

Интересно посмотреть на что указывает 3-й FD  в твоем случае ?

> [pid  5363] 00:01:24 fsync(3)   = 0

file /proc/5363/fd/3

Re: transmission-daemon и постоянные обращения к диску

2017-03-28 Пенетрантность dimas 
он плодит еще кучку потомков, для надежности запустил вот так:
strace -e open,write,close -o t-d.strace transmission-daemon \
--config-dir=.config/transmission-daemon/ -ep \
-e /var/log/transmission.log --log-error -f
выхлоп в аттаче. ничерта интересного. в лог пишет несчастную одну строчку.
шыштемд у меня нету, в syslog пару раз "closing session" выдал при остановке.

однако же, поигрался тут еще по-всякому и нашел вот какую вещь: если запустить
strace -p 5363,5364,5365,5385 -c &> stats
получаем примерно по одному fsync в секунду (см. файл stats)
далее, при логе в /var/log/transmission:
srv> ~$ strace -p 5363,5364,5365,5385 -e fsync -t
strace: Process 5363 attached
strace: Process 5364 attached
strace: Process 5365 attached
strace: Process 5385 attached
[pid  5363] 00:01:18 fsync(3)   = 0
[pid  5363] 00:01:20 fsync(3)   = 0
[pid  5363] 00:01:21 fsync(3)   = 0
[pid  5363] 00:01:22 fsync(3)   = 0
[pid  5363] 00:01:23 fsync(3)   = 0
[pid  5363] 00:01:24 fsync(3)   = 0
ну и так далее, каждую секунду он зовется и успешно синкает бедный диск. [1]
если же лог направить в /dev/null, общая картина та же, за исключением того,
что все эти fsync'и завершаются с ошибкой:
srv> ~$ strace -p 11226 -e fsync -t
strace: Process 11226 attached
00:09:30 fsync(3)   = -1 EINVAL (Invalid argument)
00:09:31 fsync(3)   = -1 EINVAL (Invalid argument)
00:09:32 fsync(3)   = -1 EINVAL (Invalid argument)
00:09:33 fsync(3)   = -1 EINVAL (Invalid argument)
00:09:34 fsync(3)   = -1 EINVAL (Invalid argument)
00:09:35 fsync(3)   = -1 EINVAL (Invalid argument)
вот она где собака порылась!
таким образом, имеем вот что: если лог-файл у нас на диске, то бешеная
программа каждую секунду упорно синкает этот самый диск! /dev/null тоже
пытается упорно синкать, но ему все равно))
видимо, где-то в коде, отвечающем за ведение логов, должно было быть что-то
типа: раз в секунду сбрасываем некий буфер (или как его правильно) в лог-файл и
синкаем диск, только из-за ошибки оно синкается независимо от того, писали мы в
файл или нет.


[1] http://man7.org/linux/man-pages/man2/fsync.2.html


2017-087 15:58 Tim Sattarov  wrote:
> я бы проверил ещё strace'ом, что он пишет и куда
> strace  -e write -p `pidof transmission-daemon`
> и вот сюда ещё:
> journalctl  -u transmission-daemon.service
> 
> у меня transmission-daemon из тестинга:
> 
> # apt-cache  policy transmission-daemon
> transmission-daemon:
>   Installed: 2.92-2
>   Candidate: 2.92-2
>   Version table:
>  *** 2.92-2 500
> 500 https://cloudfront.debian.net/debian unstable/main amd64
> Packages
> 400 https://cloudfront.debian.net/debian testing/main amd64 Packages
> 100 /var/lib/dpkg/status
> 
> 
> весь запуск и опции управляются через systemd:
> 
> [Unit]
> Description=Transmission BitTorrent Daemon
> After=network.target
> 
> [Service]
> User=debian-transmission
> Type=notify
> ExecStart=/usr/bin/transmission-daemon -f --log-error
> ExecStop=/bin/kill -s STOP $MAINPID
> ExecReload=/bin/kill -s HUP $MAINPID
> 
> [Install]
> WantedBy=multi-user.target
> 
> 


t-d.strace
Description: Binary data


stats
Description: Binary data

[systemd] [suspend] [перфекционизм] А какой сейчас документированный способ передергивания беспроводных адаптеров при спячке?

2017-03-28 Пенетрантность Dmitry Alexandrov 
Добрых суток уважаемой рассылке.

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

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

До прихода systemd в Дебиане был предусмотрен и описан в pm-action(8) интерфейс 
для настройки костыля: куда-нибудь в /etc/pm/config.d/ можно было прописать, к 
примеру, SUSPEND_MODULES="r8712u".

А что теперь?  Нет, мне, разумеется, не сложно написать два .service-файла и 
кинуть их в /etc/systemd/system/:

,
| [Unit]
| Before=hibernate.target suspend.target hybrid-sleep.target
| 
| [Service]
| Type=oneshot
| ExecStart=/sbin/modprobe -r r8712u
| 
| [Install]
| WantedBy=hibernate.target suspend.target hybrid-sleep.target
`

,
| [Unit]
| After=hibernate.target suspend.target hybrid-sleep.target
| 
| [Service]
| Type=oneshot
| ExecStart=/sbin/modprobe r8712u
| 
| [Install]
| WantedBy=hibernate.target suspend.target hybrid-sleep.target
`

Но какого-нибудь более пользовательского, документированного решения ныне в 
Дебиане из коробки не предусмотрено?

Re: transmission-daemon и постоянные обращения к диску

2017-03-28 Пенетрантность dimas 
2017-087 22:48 Igor Savlook  wrote:
> Тоесть он лог постоянно пишет на диск не прекращая? После того как ты
> лог направил в /dev/null все ок?
именно так!
причем я хз, что он туда пишет, в лог-файле ничего нового не появляется, но в
iotop при этом постоянная запись от процесса t-d.
с lsof я не особо разобрался, у него какой-то наркоманский синтаксис, плюс он
еще сетевые все запросы до кучи сыплет, и -X не помогает.
но факт в том, что после -e /dev/null все успокоилось, да

Re: transmission-daemon и постоянные обращения к диску

2017-03-28 Пенетрантность Tim Sattarov 
On 28/03/17 03:08 PM, dimas wrote:
> поставил iotop, и сабж стал постоянно светиться в столбце "write". подумал,
> куда он там может пытаться писать - первое подозрение: что-то в логи тоннами
> шлет. в syslog он не пишет, вроде как, а собственный его лог-файл я посмотрел 
> -
> там несколько строчек всего, и ничего нового не появляется. в опциях стояло
> --log-error, именно так все и работало (несколько записей про одну раздачу,
> которая не найдена на таком-то трекере)
> однако же, после того как в /etc/default/сабж я задал -e /dev/null и
> перезапустил - он перестал насиловать мой несчастный диск. а при заданном
> лог-файле не только диод моргал, но и, если ухо приложить, слышно было, как
> бедный диск заводится каждый раз.
я бы проверил ещё strace'ом, что он пишет и куда
strace  -e write -p `pidof transmission-daemon`
и вот сюда ещё:
journalctl  -u transmission-daemon.service

у меня transmission-daemon из тестинга:

# apt-cache  policy transmission-daemon
transmission-daemon:
  Installed: 2.92-2
  Candidate: 2.92-2
  Version table:
 *** 2.92-2 500
500 https://cloudfront.debian.net/debian unstable/main amd64
Packages
400 https://cloudfront.debian.net/debian testing/main amd64 Packages
100 /var/lib/dpkg/status


весь запуск и опции управляются через systemd:

[Unit]
Description=Transmission BitTorrent Daemon
After=network.target

[Service]
User=debian-transmission
Type=notify
ExecStart=/usr/bin/transmission-daemon -f --log-error
ExecStop=/bin/kill -s STOP $MAINPID
ExecReload=/bin/kill -s HUP $MAINPID

[Install]
WantedBy=multi-user.target

Re: transmission-daemon и постоянные обращения к диску

2017-03-28 Пенетрантность Igor Savlook 
On Tue, 2017-03-28 at 22:08 +0300, dimas wrote:
> алярм всем, кто пользует transmission-daemon, по крайней мере
> актуальную версию
> из тестинга!
> сегодня заметил, что на сервере постоянно мигает диод доступа к
> диску, где-то
> раз в секунду. опытным путем быстро выяснилось, что после остановки
> сабжа
> перестает мигать, с запуском - начинает. фишка в том, что диод
> отвечает за
> системный диск, на котором кроме самой системы ничего нет, вся
> файлопомойка (и
> раздачи) - на внешних дисках.
> поставил iotop, и сабж стал постоянно светиться в столбце "write".
> подумал,
> куда он там может пытаться писать - первое подозрение: что-то в логи
> тоннами
> шлет. в syslog он не пишет, вроде как, а собственный его лог-файл я
> посмотрел -
> там несколько строчек всего, и ничего нового не появляется. в опциях
> стояло
> --log-error, именно так все и работало (несколько записей про одну
> раздачу,
> которая не найдена на таком-то трекере)
> однако же, после того как в /etc/default/сабж я задал -e /dev/null и
> перезапустил - он перестал насиловать мой несчастный диск. а при
> заданном
> лог-файле не только диод моргал, но и, если ухо приложить, слышно
> было, как
> бедный диск заводится каждый раз.
> баг сейчас накатаю, если еще нету, а пока что все обратите внимание,
> если вам
> дороги ваши винты
> 

Тоесть он лог постоянно пишет на диск не прекращая? После того как ты
лог направил в /dev/null все ок?

transmission-daemon и постоянные обращения к диску

2017-03-28 Пенетрантность dimas 
алярм всем, кто пользует transmission-daemon, по крайней мере актуальную версию
из тестинга!
сегодня заметил, что на сервере постоянно мигает диод доступа к диску, где-то
раз в секунду. опытным путем быстро выяснилось, что после остановки сабжа
перестает мигать, с запуском - начинает. фишка в том, что диод отвечает за
системный диск, на котором кроме самой системы ничего нет, вся файлопомойка (и
раздачи) - на внешних дисках.
поставил iotop, и сабж стал постоянно светиться в столбце "write". подумал,
куда он там может пытаться писать - первое подозрение: что-то в логи тоннами
шлет. в syslog он не пишет, вроде как, а собственный его лог-файл я посмотрел -
там несколько строчек всего, и ничего нового не появляется. в опциях стояло
--log-error, именно так все и работало (несколько записей про одну раздачу,
которая не найдена на таком-то трекере)
однако же, после того как в /etc/default/сабж я задал -e /dev/null и
перезапустил - он перестал насиловать мой несчастный диск. а при заданном
лог-файле не только диод моргал, но и, если ухо приложить, слышно было, как
бедный диск заводится каждый раз.
баг сейчас накатаю, если еще нету, а пока что все обратите внимание, если вам
дороги ваши винты

[DONE] wml://{security/2017/dsa-3823.wml}

2017-03-28 Пенетрантность Lev Lamberov 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

- --- english/security/2017/dsa-3823.wml2017-03-28 20:42:31.0 
+0500
+++ russian/security/2017/dsa-3823.wml  2017-03-28 22:26:17.064131506 +0500
@@ -1,17 +1,18 @@
- -security update
+#use wml::debian::translation-check translation="1.1" maintainer="Lev Lamberov"
+обновление 
безопасности
 
- -Ilja Van Sprundel discovered that the dmcrypt-get-device helper used to
- -check if a given device is an encrypted device handled by devmapper, and
- -used in eject, does not check return values from setuid() and setgid()
- -when dropping privileges.
+Илья ван Шпрундель обнаружил, что 
вспомогательный инструмент dmcrypt-get-device,
+используемый для проверки того, что данное 
устройство является зашифрованным 
устройством,
+обслуживаемым с помощью devmapper, а также 
используемый в утилите eject, не выполняет
+проверку возвращаемых значений функций 
setuid() и setgid() при сбросе привилегий.
 
- -For the stable distribution (jessie), this problem has been fixed in
- -version 2.1.5+deb1+cvs20081104-13.1+deb8u1.
+В стабильном выпуске (jessie) эта проблема 
была исправлена в
+версии 2.1.5+deb1+cvs20081104-13.1+deb8u1.
 
- -For the unstable distribution (sid), this problem has been fixed in
- -version 2.1.5+deb1+cvs20081104-13.2.
+В нестабильном выпуске (sid) эта проблема 
была исправлена в
+версии 2.1.5+deb1+cvs20081104-13.2.
 
- -We recommend that you upgrade your eject packages.
+Рекомендуется обновить пакеты eject.
 
 
 # do not modify the following line
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE3mumcdV9mwCc9oZQXudu4gIW0qUFAljanL0ACgkQXudu4gIW
0qUi4w/+IsfcqVGD9F2vtdpU+M7REm8p17dbwZDBe6826ImXdCAZ9SaYIvTF/yun
VqaVIX7iAw6CKdAggBSWbX4dZz42Rz7d+qgQKGvX15oiRiqxnMfy+xYxslKPUmql
KTq8yKg0A60LtQ0AuoTJF5G51V+SpwKgfJTsTO/Q2OFZClZRAkiYburzmauOSvvG
30JiCF4O88occzppqZ0aIwUeBIX+mHs9igMQOjyvCcw/hpMYORJodWLzaklZE96q
0w2beTCfqSVIS8KsQWdDN9topzbrjejPQEcdpPM7C9OOQ3bRPtoEk5aFTA4d56bM
SdHfS+3AQZfd88QRbwnLFhnpWf3hJekg+yvAUgVAAOchz1sScr8tPMKI5fhS6akn
lXXLbBlFa6JOlgTJKDeZuSr+Y7QPH0ihuo5Sz/Nt7WllURf6pkrPZUtFP9gk9QOQ
CUlLQtOk0Oro930A993cRcnhOjHSu1p8GWnjcpB+f6bnFF4/L2gmbAXJE6C8b4e6
Ov+U6xTD5DjGzRNctqNeq0rAcR2CdVQh79wrMunivIUJCJHjQr9BPmxkWYvjZHmp
ttBeiowsRcmnRPUhX+ElUaU8Z24g8O4yjL8YcCdO7GSduxNl2IpnGoNgKhlfNDts
MQKMqBNC7fceXqG5sO69iqvdNGn8CJBHqxpnks1o14n8d4B5txI=
=jV6h
-END PGP SIGNATURE-

Re: postgres open file limits

2017-03-28 Пенетрантность Vasiliy P. Melnik 
Прошел год :)

Опять столкнулся с ситуацией, только на этот раз уже такого параметра в
конфиге не было, на этот раз это был riak. Делюсь, ибо ушло кучу времени на
всякие эксперименты.

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

Создать директорию для кастомного конфига
mkdir -p /etc/systemd/system/riak.service.d/

Нюанс:
хоть systemctrl и реагирует на команду вида systemctrl restart riak , путь
надо создавать полный, в данном случае не riak.service.d, но не riak.d

Создать файл /etc/systemd/system/riak.service.d/LimitNOFILE.conf (название
любое.conf) со следующим содержимым
[Service]
LimitNOFILE=204800

systemctl reenable riak.service


19 февраля 2016 г., 17:03 пользователь Anatoliy Dmytriyev <
tolid-deb...@tolid.eu.org> написал:

> Вставить ulimit в init.d скрипте?
>
> Regards,
> Anatoliy
>
>
>
> > On 14 Feb 2016, at 10:38, Vasiliy P. Melnik  wrote:
> >
> > HI all
> >
> > Кто пользуется постгресом, посмотрите лимиты на отрытые файлы
> >
> > cat /proc/`lsof -i4 -n -P | grep 5432 | awk '{print $2}'`/limits | grep
> "open files"
> > Max open files1024 4096 files
> >
> > настройки в /etc/security/limits.conf postgresql просто игнорирует.
> >
> > Мастер процессу поднять Max open files можно, но толку от этого никакого
> - все сабпроцессы созданные мастером все равно имеют ограничение в 1024.
> Пользователь postgres если под ним залогиниться ограничений не имеет
> >
> > системы дебиан 83 и  71 - поведение одинаковое, постгрес 9.2 из репо
> постгреса, постгрес 9.4 из  дебиана
> >
> >
> > Кто-то знает как ему затолкать лимиты? кроме как кроном обходить все
> процессы постгреса и менять лимит пока ничего другого не придумал
>
>

Validation failed

2017-03-28 Пенетрантность Debian Webmaster 
*** Errors validating
/srv/www.debian.org/www/international/l10n/po/en_GB.ru.html: ***
Line 117, character 351:  "128513" is not a character number in the
document character set
Line 305, character 337:  "128513" is not a character number in the
document character set
Line 1312, character 241:  "128513" is not a character number in the
document character set

--
 You received this mail for the language code ru.
 Please edit webwml/english/devel/website/validation.data if this is not 
accurate
 Please also update webwml/english/devel/website/ with the new coordinator(s) 
data

Re: чистка psql_history

2017-03-28 Пенетрантность Victor Wagner 
On Mon, 27 Mar 2017 15:48:33 +0300
Anton Gorlov  wrote:

> All,а подскажите кто отвечает за чистку .psql_history?
> периодически замечаю что оно чистится..а откуда руки растут.. сходу
> не вижу
> 

Собственно сам psql и занимается. Он при записи  истории вызывает
history_truncate_file, чтобы файл истории не разразстался.

Можно этот размер менять с помощью

\set HISTSIZE сколько-надо

(например из ~/.psqlrc).
Если поставить отрицательный лимит, он перестанет урезать историю.

[DONE] wml://security/2017/dsa-38{18,19,20,21,22}.wml

2017-03-28 Пенетрантность Lev Lamberov 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

- --- english/security/2017/dsa-3818.wml2017-03-28 10:51:46.0 
+0500
+++ russian/security/2017/dsa-3818.wml  2017-03-28 10:57:25.335562800 +0500
@@ -1,20 +1,21 @@
- -security update
+#use wml::debian::translation-check translation="1.1" maintainer="Lev Lamberov"
+обновление 
безопасности
 
- -Hanno Boeck discovered multiple vulnerabilities in the GStreamer media
- -framework and its codecs and demuxers, which may result in denial of
- -service or the execution of arbitrary code if a malformed media file is
- -opened.
+Ханно Бёк обнаружил многочисленные 
уязвимости в GStreamer, мультимедиа
+инфраструктуре, её кодеках и 
демультиплексорах, которые могут 
приводить к отказу
+в обслуживании или выполнению 
произвольного кода в случае открытия 
специально
+сформированного мультимедиа-файла.
 
- -For the stable distribution (jessie), these problems have been fixed in
- -version 1.4.4-2.1+deb8u2.
+В стабильном выпуске (jessie) эти проблемы 
были исправлены в
+версии 1.4.4-2.1+deb8u2.
 
- -For the upcoming stable distribution (stretch), these problems have been
- -fixed in version 1.10.4-1.
+В готовящемся стабильном выпуске (stretch) 
эти проблемы были
+исправлены в версии 1.10.4-1.
 
- -For the unstable distribution (sid), these problems have been fixed in
- -version 1.10.4-1.
+В нестабильном выпуске (sid) эти проблемы 
были исправлены в
+версии 1.10.4-1.
 
- -We recommend that you upgrade your gst-plugins-bad1.0 packages.
+Рекомендуется обновить пакеты 
gst-plugins-bad1.0.
 
 
 # do not modify the following line
- --- english/security/2017/dsa-3819.wml2017-03-28 10:52:12.0 
+0500
+++ russian/security/2017/dsa-3819.wml  2017-03-28 10:59:44.887020143 +0500
@@ -1,20 +1,21 @@
- -security update
+#use wml::debian::translation-check translation="1.1" maintainer="Lev Lamberov"
+обновление 
безопасности
 
- -Hanno Boeck discovered multiple vulnerabilities in the GStreamer media
- -framework and its codecs and demuxers, which may result in denial of
- -service or the execution of arbitrary code if a malformed media file is
- -opened.
+Ханно Бёк обнаружил многочисленные 
уязвимости в GStreamer, мультимедиа
+инфраструктуре, её кодеках и 
демультиплексорах, которые могут 
приводить к отказу
+в обслуживании или выполнению 
произвольного кода в случае открытия 
специально
+сформированного мультимедиа-файла.
 
- -For the stable distribution (jessie), these problems have been fixed in
- -version 1.4.4-2+deb8u1.
+В стабильном выпуске (jessie) эти проблемы 
были исправлены в
+версии 1.4.4-2+deb8u1.
 
- -For the upcoming stable distribution (stretch), these problems have been
- -fixed in version 1.10.4-1.
+В готовящемся стабильном выпуске (stretch) 
эти проблемы были
+исправлены в версии 1.10.4-1.
 
- -For the unstable distribution (sid), these problems have been fixed in
- -version 1.10.4-1.
+В нестабильном выпуске (sid) эти проблемы 
были исправлены в
+версии 1.10.4-1.
 
- -We recommend that you upgrade your gst-plugins-base1.0 packages.
+Рекомендуется обновить пакеты 
gst-plugins-base1.0.
 
 
 # do not modify the following line
- --- english/security/2017/dsa-3820.wml2017-03-28 10:52:39.0 
+0500
+++ russian/security/2017/dsa-3820.wml  2017-03-28 11:00:57.803158867 +0500
@@ -1,20 +1,21 @@
- -security update
+#use wml::debian::translation-check translation="1.1" maintainer="Lev Lamberov"
+обновление 
безопасности
 
- -Hanno Boeck discovered multiple vulnerabilities in the GStreamer media
- -framework and its codecs and demuxers, which may result in denial of
- -service or the execution of arbitrary code if a malformed media file is
- -opened.
+Ханно Бёк обнаружил многочисленные 
уязвимости в GStreamer, мультимедиа
+инфраструктуре, её кодеках и 
демультиплексорах, которые могут 
приводить к отказу
+в обслуживании или выполнению 
произвольного кода в случае открытия 
специально