счетчик used у свопа работает по принципу «только прибавляем».
[19:32]# swapinfo
Device 1K-blocks Used Avail Capacity
/dev/ada0b 5022720 311000 4711720 6%
[21:30]# swapinfo
Device 1K-blocks Used Avail Capacity
/dev/ada0b 5022720 309288 4713432 6%
т.е. работает и на освобожение.
Другой вопрос зачем он вообще используется при 13G Free (и с момента старта системы Free ниже 12 не опускалась).
Mem: 20M Active, 244M Inact, 2206M Wired, 10M Cache, 1643M Buf, 13G Free
Swap: 4905M Total, 303M Used, 4602M Free, 6% Inuse
Но вопрос свопа второстепенен.
Мне кажется, это проблема tmpfs.
Нет, проблемы проявляются и без него. Я задействовал tmpfs просто для наглядности.
Для того, чтобы обезопасить себя от атаки с использованием данной ошибки безопасности, следует осуществить следующие действия:
Отключить IPv6-адресацию…
1) Upgrade your vulnerable system to a supported FreeBSD stable or
release / security branch (releng) dated after the correction date.
Rebooting to the new kernel is required.
2) To update your vulnerable system via a binary patch:
Systems running a RELEASE version of FreeBSD on the i386 or amd64
platforms can be updated via the freebsd-update(8) utility:
# freebsd-update fetch
# freebsd-update install
Rebooting to the new kernel is required.
3) To update your vulnerable system via a source code patch:
The following patches have been verified to apply to the applicable
FreeBSD release branches.
a) Download the relevant patch from the location below, and verify the
detached PGP signature using your PGP utility.
В этом случае и history -c будет бесмысленным, т.к. при history -S буфер сбросится в ~/.history, но дефолтный alias postcmd отсутствует, поэтому это уже отличные от «по умолчанию» настройки.
Тут, возможно, чтобы подчистить придётся подредактировать ~/.history перед уходом.
Хотя скорее всего даже kill -9 $$ при этом отлогируется в ~/.history
Логики вышеописанного это не меняет, запросы всё-равно попадут в ngx_http_form_input_post_read(ngx_http_request_t *r).
Только разбор JSON опять же придётся отдать на откуп этому модулю.
Код модуля смотрел очень давно, не помню. Но если обработки в нём и нет, то добавить её не так сложно.
Самим модулем пользовался на нагрузке около 100k per sec, падений не было.
— пайпим данные напрямую без php-шной обработки # tail -F /var/log/nginx/fifo.mylog | mysql -pMYSQL_PASS
Вероятнее всего, для того чтобы данные полились придётся рестратануть (НЕ reload) nginx, чтобы он нашёл fifo.
С таким потоком данных по поводу flush'a буферов можно не заморачиваться.
Тем самым input-переменные не требующие дополнительной обработки льются напрямую без всякого php.
Из статьи не понятна структура таблиц/запросов. Но вероятнее всего под такой нагрузкой хранятся пары вида «ключ, значение».
Если так, то не лучше ли перейти на решения а-ля redis?
Если по каким-то причинам no-sql решения не подходят, а структура запросов INSERT одинакова гоните их в mysql через fifo pipe напрямую.
Не доверяйте просто так подсетям ПС. Они далеко не безгрешны. Парсинг 2-х летней давности с серверов Яндекса:
Около 3'000'000 запросов за сутки. Разумеется никакими Яндекс-ботами здесь и не пахнет
[19:32]# swapinfo
Device 1K-blocks Used Avail Capacity
/dev/ada0b 5022720 311000 4711720 6%
[21:30]# swapinfo
Device 1K-blocks Used Avail Capacity
/dev/ada0b 5022720 309288 4713432 6%
т.е. работает и на освобожение.
Другой вопрос зачем он вообще используется при 13G Free (и с момента старта системы Free ниже 12 не опускалась).
Mem: 20M Active, 244M Inact, 2206M Wired, 10M Cache, 1643M Buf, 13G Free
Swap: 4905M Total, 303M Used, 4602M Free, 6% Inuse
Но вопрос свопа второстепенен.
Нет, проблемы проявляются и без него. Я задействовал tmpfs просто для наглядности.
Выделяю 100M блоками пока не произойдёт исключение и освобождаю.
В итоге Cache вообще остался нетронут, Inact похудел на 52G. Но как выяснить, что эти 52G были доступны?
Да вы страшные люди…
V. Solution
Perform one of the following:
1) Upgrade your vulnerable system to a supported FreeBSD stable or
release / security branch (releng) dated after the correction date.
Rebooting to the new kernel is required.
2) To update your vulnerable system via a binary patch:
Systems running a RELEASE version of FreeBSD on the i386 or amd64
platforms can be updated via the freebsd-update(8) utility:
Rebooting to the new kernel is required.
3) To update your vulnerable system via a source code patch:
The following patches have been verified to apply to the applicable
FreeBSD release branches.
a) Download the relevant patch from the location below, and verify the
detached PGP signature using your PGP utility.
b) Apply the patch. Execute the following commands as root:
c) Recompile your kernel as described in
<URL:https://www.FreeBSD.org/handbook/kernelconfig.html> and reboot the
system.
>>
Тут, возможно, чтобы подчистить придётся подредактировать ~/.history перед уходом.
Хотя скорее всего даже kill -9 $$ при этом отлогируется в ~/.history
здесь вообще лишнее, т.к. история фиксируется в ~/.history про логауте, а при
у нас не будет корректного выхода и как следствие история не зафиксируется
Тут же для борьбы с инъекциями (о которых подымал вопрос aleks_raiden)можно использовать github.com/openresty/set-misc-nginx-module#set_quote_sql_str
Только разбор JSON опять же придётся отдать на откуп этому модулю.
Самим модулем пользовался на нагрузке около 100k per sec, падений не было.
навскидку сохраняя структуру, логику, не уходя от mysql и не писав собственного модуля для nginx:
— добавляем в nginx модуль HttpFormInputModule от taobao
— делаем
log_format mylog 'INSERT IGNORE INTO `log`.`access` (`user`, `data1`, `data2`) VALUES ("$post_user","$post_data1","$post_data2");\n';логируем в нужном локейшине
— создаём fifo-шку
# mkfifo /var/log/nginx/fifo.mylog && chmod 666 /var/log/nginx/fifo.mylog— пайпим данные напрямую без php-шной обработки
# tail -F /var/log/nginx/fifo.mylog | mysql -pMYSQL_PASSВероятнее всего, для того чтобы данные полились придётся рестратануть (НЕ reload) nginx, чтобы он нашёл fifo.
С таким потоком данных по поводу flush'a буферов можно не заморачиваться.
Тем самым input-переменные не требующие дополнительной обработки льются напрямую без всякого php.
Если так, то не лучше ли перейти на решения а-ля redis?
Если по каким-то причинам no-sql решения не подходят, а структура запросов INSERT одинакова гоните их в mysql через fifo pipe напрямую.
Стерео с пружинным ревербератором.
Тоже на ходу, иглы только подгулявшие.
«Старт 2», 58 или 59-го года выпуска.
И он и все остальные на фото в исправном состоянии.
Хм, а читается как английский :)
drwatson32, спасибо, весьма занимательное чтиво