А кто-то пробовал прозрачно переносить историю заббикса из postgresql в кликхаус используя fdw? https://github.com/adjust/clickhouse_fdw.
Я вот только что поднял на коленке — базово работает, интересно что по производительности и точности данных. Из патчей только один в в веб-интерфейсе
Это да, но ты пойди до него еще доберись, если там стоит какой-нибудь CHAOS+tarpit и сам ссш на высоких портах. От ботов хватает даже банального правила на DROP + перевешивания на высокий порт. А не от ботов — алерт на auth логи.
Ну, я вот почему-то предполагаю что в ЧГК участвуют студенты и не самые глупые студенты. Наверняка хотя бы один АСУшник у них был. Опять таки преподаватели могли иметь практический опыт построения этой системы. Студенты могли иметь доступ на предприятия с мощным оборудованием которое включается-выключается. Если точно измерять частоту — можно замерить реакцию системы на импульсное воздействие и определить порядок передаточной функции. Сейчас уже не помню все, но методы исследования систем есть и проходятся в универе.
Не только. Сглаживание пиков потребления и как следствие оптимальный режим работы генераторов кмк было основной целью. Страна в куче часовых поясов, где-то ночь и мало потребления, где-то день и пиковое.
Вот кстати да, для солнечной энергии еэс становится хорошей альтернативой аккумуляторам.
Я слышал что СССР была единая энергосистема и частота и фаза генераторов по все стране была одинаковой (а иначе как их еще объединить систему). Соответственно, получить сведения о текущей частоте сети было просто. То что частота связана с нагрузкой — это элементарно и проходилось наверное даже в школе. Падает нагрузка — растет скорость вращения турбин. Влияние включения — выключения телевизоров — тоже вполне реально, т.к. вполне могли оставаться ламповые телевизоры, который потребляли кучу энергии. Если синхронизировать моменты выключения — полагаю что скачок по частоте вполне реально было уловить.
Я тут статью вспоминаю про то что ключ зашифрованный паролем аналогичен ключу без пароля. Не знаю насколько она актуальна, но все же лучше этот ключ зашифровать дополнительно. https://habr.com/ru/company/wirex/blog/419829/
Ну нет же. Ключ может храниться на неизвлекаемом носителе. Например тот же TPM. Пароль надо вводить при каждом логине на сервер, ключ может быть расшифрован один раз и храниться ssh-agent'ом. Один ключ может безопасно использоваться для входа на несколько серверов, пароль — нет. Ваш пароль передается на удаленный серевер и легко может быть извлечен рутом на сервере куда вы логинитесь (как пример — специальный pam модуль). Единственный плюс пароля — отсутствие необходимости хранить ключ.
Тем что пароль передается на удаленный сервер в открытом виде и если он (сервер) скомпроментирован, будет скомпроментирован и ваш пароль при логине. Если вы его используете на нескольких серверах — будет получен доступ и к ним. Если же вы генерируете пароли для каждого сервера — то в практическом плане ключ удобнее тем что он безопасно может быть один для доступа на многие сервера.
Ого. Интересно.Заставило почитать исходный код. Вы ведь используете репликацию с hot_standby_feedback? Как я понял standby вычисляет и посылает в этом случае ид транзакции с мастера (на standby нет своих номеров транзакций), которая еще хранит нужные ему строки и мастер не очищает строки чтобы не удалить строки которые нужны на standby.
При этом truncate таким не страдает и спокойно очищает строки. Интересно, vacuum full это по сути запрос cluster, но в нем все равно проверяется какие строки должны оставаться видимы.
VACUUM FULL все же накладывает эксклюзивную блокировку (ожидает завершения транзакций на таблице). Проверить просто — открыть два окна, в одном начать транзакцию и выбрать что-то из таблицы, в другом выполнитьVACUUM FULL. Он не начнется пока не будет завершена транзакция в другом окне.
Соглашусь с предыдущим комментарием — выглядит так, как будто можно заменить на
SET statement_timeout = '1s';
VACUUM FULL table_name;
Спасибо за статью, узнал про запрос TABLE.
Возник вопрос — чем не подошел pg_repack?
И еще дополнение — в приведенном запросе имена индексов не сохранятся, добавится префикс swap. И так каждый раз.
Заголовок спойлера
CREATE TABLE _swap_%table(LIKE %table INCLUDING ALL);
INSERT INTO _swap_%table TABLE %table;
DROP TABLE %table;
ALTER TABLE _swap_%table RENAME TO %table;
Статью не обещаю. Напишу только что
1) если почта корпоративная — все записи dkim+spf+dmarc настраивает ваш админ на вашем домене. И он волен крутить ручки как угодно. Другое дело что строгие правила редко где нужны. (Лучше пусть кто-то напишет от вашего имени чем письмо не дойдет).
2) у гугла так сделано потому что если сделать более строгие требования есть большие шансы что поломается почта у тех кто пользуется пересылкой (а вы не хотите чтобы ваша почта терялась)
Видимо гугл на домене gmail уповает на другие механизмы защиты от спама.
Хочу добавить: это не критика автора статьи, статья очень крутая, я восхищен анимацией, собранной статистикой и слогом. Больше тут недоумение реакцией и критикой сервиса такси. Каммон, это действительно не та информация, которую стоит как-то сильно защищать.
Впервые проявил активность и сразу насрали в карму. Следующую статью предлагаю написать про яндекс такси с предложением парсить их представителям Ситимобил. Точно такой же запрос без авторизации. Точно так же возвращаются ид машин. Рейтлимит не проверял, скорее всего его нет.
После чего пишем статью про gmail, они неправильно настроили spf+dmarc
~all — разрешает подделывать адреса отправителей, т.е. любой может написать от вашего адреса почты. DMARC политика установлена в none что также разрешает всякие непотребства. Ждем)
Есть такая штука — Residential Proxies. В итоге как обычно — защита обходится не так сложно. Но в то же время доставит проблемы легитимным пользователям впн.
Что есть тенденция из-за наших новых законов и из-за блокировок гнать весь трафик через зарубежный впн. И такие блокировщики по AS доставляют боль. Иногда проще отказать от сервиса чем отключать ради него впн.
В некоторых сервисах такси есть такая штука — вызов такси кому-то в другой части города. Есть например в том же яндексе. И точно так же показываются машины рядом. Удобная штука. А вот вы предложили сделать ее менее удобной.
А кто-то пробовал прозрачно переносить историю заббикса из postgresql в кликхаус используя fdw? https://github.com/adjust/clickhouse_fdw.
Я вот только что поднял на коленке — базово работает, интересно что по производительности и точности данных. Из патчей только один в в веб-интерфейсе
Это да, но ты пойди до него еще доберись, если там стоит какой-нибудь CHAOS+tarpit и сам ссш на высоких портах. От ботов хватает даже банального правила на DROP + перевешивания на высокий порт. А не от ботов — алерт на auth логи.
Ну, я вот почему-то предполагаю что в ЧГК участвуют студенты и не самые глупые студенты. Наверняка хотя бы один АСУшник у них был. Опять таки преподаватели могли иметь практический опыт построения этой системы. Студенты могли иметь доступ на предприятия с мощным оборудованием которое включается-выключается. Если точно измерять частоту — можно замерить реакцию системы на импульсное воздействие и определить порядок передаточной функции. Сейчас уже не помню все, но методы исследования систем есть и проходятся в универе.
Не только. Сглаживание пиков потребления и как следствие оптимальный режим работы генераторов кмк было основной целью. Страна в куче часовых поясов, где-то ночь и мало потребления, где-то день и пиковое.
Вот кстати да, для солнечной энергии еэс становится хорошей альтернативой аккумуляторам.
Я слышал что СССР была единая энергосистема и частота и фаза генераторов по все стране была одинаковой (а иначе как их еще объединить систему). Соответственно, получить сведения о текущей частоте сети было просто. То что частота связана с нагрузкой — это элементарно и проходилось наверное даже в школе. Падает нагрузка — растет скорость вращения турбин. Влияние включения — выключения телевизоров — тоже вполне реально, т.к. вполне могли оставаться ламповые телевизоры, который потребляли кучу энергии. Если синхронизировать моменты выключения — полагаю что скачок по частоте вполне реально было уловить.
Я тут статью вспоминаю про то что ключ зашифрованный паролем аналогичен ключу без пароля. Не знаю насколько она актуальна, но все же лучше этот ключ зашифровать дополнительно. https://habr.com/ru/company/wirex/blog/419829/
Ну нет же. Ключ может храниться на неизвлекаемом носителе. Например тот же TPM. Пароль надо вводить при каждом логине на сервер, ключ может быть расшифрован один раз и храниться ssh-agent'ом. Один ключ может безопасно использоваться для входа на несколько серверов, пароль — нет. Ваш пароль передается на удаленный серевер и легко может быть извлечен рутом на сервере куда вы логинитесь (как пример — специальный pam модуль). Единственный плюс пароля — отсутствие необходимости хранить ключ.
Тем что пароль передается на удаленный сервер в открытом виде и если он (сервер) скомпроментирован, будет скомпроментирован и ваш пароль при логине. Если вы его используете на нескольких серверах — будет получен доступ и к ним. Если же вы генерируете пароли для каждого сервера — то в практическом плане ключ удобнее тем что он безопасно может быть один для доступа на многие сервера.
Ого. Интересно.Заставило почитать исходный код. Вы ведь используете репликацию с hot_standby_feedback? Как я понял standby вычисляет и посылает в этом случае ид транзакции с мастера (на standby нет своих номеров транзакций), которая еще хранит нужные ему строки и мастер не очищает строки чтобы не удалить строки которые нужны на standby.
При этом truncate таким не страдает и спокойно очищает строки. Интересно, vacuum full это по сути запрос cluster, но в нем все равно проверяется какие строки должны оставаться видимы.
https://github.com/postgres/postgres/blob/8ce3aa9b5914d1ac45ed3f9bc484f66b3c4850c7/src/backend/commands/cluster.c#L864
egorov, звучит как тема для еще одной статьи — как работает host_standby_feedback и на что он влияет на мастере)
VACUUM FULL
все же накладывает эксклюзивную блокировку (ожидает завершения транзакций на таблице). Проверить просто — открыть два окна, в одном начать транзакцию и выбрать что-то из таблицы, в другом выполнитьVACUUM FULL
. Он не начнется пока не будет завершена транзакция в другом окне.Соглашусь с предыдущим комментарием — выглядит так, как будто можно заменить на
Спасибо за статью, узнал про запрос
TABLE
.Возник вопрос — чем не подошел pg_repack?
И еще дополнение — в приведенном запросе имена индексов не сохранятся, добавится префикс swap. И так каждый раз.
Статью не обещаю. Напишу только что
1) если почта корпоративная — все записи dkim+spf+dmarc настраивает ваш админ на вашем домене. И он волен крутить ручки как угодно. Другое дело что строгие правила редко где нужны. (Лучше пусть кто-то напишет от вашего имени чем письмо не дойдет).
2) у гугла так сделано потому что если сделать более строгие требования есть большие шансы что поломается почта у тех кто пользуется пересылкой (а вы не хотите чтобы ваша почта терялась)
Видимо гугл на домене gmail уповает на другие механизмы защиты от спама.
Хочу добавить: это не критика автора статьи, статья очень крутая, я восхищен анимацией, собранной статистикой и слогом. Больше тут недоумение реакцией и критикой сервиса такси. Каммон, это действительно не та информация, которую стоит как-то сильно защищать.
Я обычно использую sslsplit. Вот что сходу нашлось. Для других сервисов думаю можно найти аналогично.
Впервые проявил активность и сразу насрали в карму. Следующую статью предлагаю написать про яндекс такси с предложением парсить их представителям Ситимобил. Точно такой же запрос без авторизации. Точно так же возвращаются ид машин. Рейтлимит не проверял, скорее всего его нет.
После чего пишем статью про gmail, они неправильно настроили spf+dmarc
~all — разрешает подделывать адреса отправителей, т.е. любой может написать от вашего адреса почты. DMARC политика установлена в none что также разрешает всякие непотребства. Ждем)
СравниТакси? Приложение для телефонов. Или надо программно?
Есть такая штука — Residential Proxies. В итоге как обычно — защита обходится не так сложно. Но в то же время доставит проблемы легитимным пользователям впн.
Думаю те, кто ходят готовы к этому. Вопрос в том, готов ли бизнес потерять клиента (а значит и деньги) из-за странной политики к пользователям впн.
Что есть тенденция из-за наших новых законов и из-за блокировок гнать весь трафик через зарубежный впн. И такие блокировщики по AS доставляют боль. Иногда проще отказать от сервиса чем отключать ради него впн.
В некоторых сервисах такси есть такая штука — вызов такси кому-то в другой части города. Есть например в том же яндексе. И точно так же показываются машины рядом. Удобная штука. А вот вы предложили сделать ее менее удобной.