Чем ЦОД отличается от дачи? Да ничем!
В ЦОДе заботятся о стойках, охлаждении и аптайме. А на даче об углях, мангале и шашлыке. И там и там важно ничего не сжечь.
ㅤ
Короче я на пару дней укатил за город и прихватил готовый «старт-пак» дачника, буду разгребать хлам, высаживать кусты и чилить.
Что входит в набор дачника: кепка, металлическая кружка, ланч-бокс с приборами и шоппер. Самый необходимый минимум.
❄ Кепка: Защищает лысину от выгорания.
❄ Кружка: Для холодного пива.
❄ Ланч-бокс: Для шашлыка.
❄ Шоппер: Замена рюкзака, под девайсы.
Этот «старт-пак» я получил от Selectel — они не только про дата-центры, но и про экологию.
😀 😃 😄 😁 😅 😂 🤣 😊
😇 🙂 🙃 😉 😌 😍 🥰 😘
😗 😙 😚 😋 😛 😝 😜 🤪
🤨 🧐 🤓 😎 🤩 🥳 😏 😒
😞 😔 😟 😕 🙁 ☹ 😣 😖
😫 😩 🥺 😢 😭 😤 😠 😡
Формула простая: 1 сервер = 1 дерево. Это основа акции «Зеленый Selectel». За всё время было засажено 38 гектаров или 160к деревьев. Сильно!
Как вариант — если у тебя дома греется self-hosted сервак или подгорает пятая точка от бесполезных созвонов — посади в каждой комнате по 3 дерева и не трать деньги на оверпрайс решения для охлаждения.
Ладно, всех с пятницей, хороших тебе предстоящих выходных и береги себя!
🛠 #рабочиебудни
—
✅ @bashdays ✅ @linuxfactory ✅ @blog
В ЦОДе заботятся о стойках, охлаждении и аптайме. А на даче об углях, мангале и шашлыке. И там и там важно ничего не сжечь.
ㅤ
Короче я на пару дней укатил за город и прихватил готовый «старт-пак» дачника, буду разгребать хлам, высаживать кусты и чилить.
Что входит в набор дачника: кепка, металлическая кружка, ланч-бокс с приборами и шоппер. Самый необходимый минимум.
Этот «старт-пак» я получил от Selectel — они не только про дата-центры, но и про экологию.
Все элементарно: в ЦОДах используются чиллеры и кондиционеры, а в природе роль «системы охлаждения» берут на себя деревья. Если ты ходил в школу, то должен быть в курсе.
Деревья испаряют влагу, дают тень и снижают температуру вокруг, получается что-то вроде природного «free cooling/халявное охлаждение».
Формула простая: 1 сервер = 1 дерево. Это основа акции «Зеленый Selectel». За всё время было засажено 38 гектаров или 160к деревьев. Сильно!
Как вариант — если у тебя дома греется self-hosted сервак или подгорает пятая точка от бесполезных созвонов — посади в каждой комнате по 3 дерева и не трать деньги на оверпрайс решения для охлаждения.
Ладно, всех с пятницей, хороших тебе предстоящих выходных и береги себя!
Selectel для охлаждения высаживает лес, а я сегодня для охлаждения высажу пару банок холодного пива.
—
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
12 53
Есть такая книга — «Не работайте с мудаками». Я ее не читал, но вся суть в названии. Ща расскажу поучительную историю.
ㅤ
Отдел продаж разжился постоянным клиентом, успешно работают с ним 5 и более лет, сайтики там рисуют, CI/CD настраивают и т.п. Для постоянного клиента все блага, фиксированные скидки, обработка экстравагантных запросов, отлизывание жопы, где-то даже бесплатно, полное доверие.
В какой-то момент, у постоянного клиента меняется менеджер. Прилетает очередная таска на доработку. Доработки сделаны, но менеджер визжит-пищит и орет — я просил другое!
По ТЗ все гладко, перепроверяют, как просили — так и сделали. Не доебаться!
Но нет, откуда-то берутся новые вводные. Новые вводные предварительно озвучены не были. Вводные в голове нового менеджера, которые он получил из космоса. То, что их нет в ТЗ, это сугубо личные проблемы исполнителя.
Кто виноват? Конечно — исполнитель! Он должен был догадаться сам. А значит виноват — исполнитель!
Исполнитель пробует решить всё миром, объясняет, так и так, что это дополнительные человеко-часы, в договоре такого нет, нужно доплатить и вообще так не делается.
По итогу — виноват исполнитель, переделывайте за свой счет.
Классика! Ну такое себе…
Что имеем: С таким менеджером дальше работать никто не будет, искать концы до главного босса тем более (других клиентов жопой ешь). Конфликт конечно же нужно уладить, спустить на тормозах. Мы же взрослые люди. Но на этом увы всё, сотрудничество закончено!
В таких ситуациях не стоит хамить, нужно разобраться и найти какие-то общие точки соприкосновений.
Искать правду и что-то доказывать смысла нет, если человек живет в своем мире, его от туда уже не вытащить. И нужно ли вытаскивать? Ему там комфортно, он таким уродился!
Не профессионально? Вопрос не корректный, тратить время на выяснения отношений себе дороже, дешевле распрощаться, проще освободить ресурс и взять нового клиента. Виз из Спарта!
Конфликт решается просто — ок, сделаем как вы хотите. Пусть думают что всё пошло по их правилам, но это лишь начало конца.
Это наглядный пример, как один менеджер способен за полчаса уничтожить протоптанные годами мосты сотрудничества.
Теперь сайтики и CI/CD, бывшему клиенту обойдутся в x2-x3 дороже, потому что рыночные цены ушагали вперед семимильными шагами, даже на фрилансе.
Мосты сожжены, а реквест на расторжение договора выслан по почте. Всё рамках трудовых отношений.
Подведем итоги:
Если у тебя свой бизнес, всегда контролируй основные звенья своего коллектива. Либо делегируй этот контроль проверенным людям.
Но порой и проверенные люди тоже дают сбой (оказываются пидарасами), это как продакшен. Продакшен в 99% случаев тот еще пидарас.
Поэтому изредка сам вылазий из берлоги и проходись по всем процессам самостоятельно, узнаешь много нового и (интересного) хуевого.
Ну а если это твой основной заказчик (который делает тебе 90% прибыли), найди выходы на главного и обсуди все вопросы с ним, благо это делается на раз-два. Менеджер уйдет сразу нахуй и будет выкинут на улицу. Проходили, знаем.
Большего и не скажешь. Если читал книгу «Не работайте с мудаками» расскажи в паре слов, о чем она. А то всё руки не дойдут полистать.
😀 😃 😄 😁 😅 😂 🤣 😊
😇 🙂 🙃 😉 😌 😍 🥰 😘
😗 😙 😚 😋 😛 😝 😜 🤪
🤨 🧐 🤓 😎 🤩 🥳 😏 😒
😞 😔 😟 😕 🙁 ☹️ 😣 😖
😫 😩 🥺 😢 😭 😤 😠 😡
Спасибо за внимание и до свидания!
🛠 #рабочиебудни
—
✅ @bashdays ✅ @linuxfactory ✅ @blog
ㅤ
Отдел продаж разжился постоянным клиентом, успешно работают с ним 5 и более лет, сайтики там рисуют, CI/CD настраивают и т.п. Для постоянного клиента все блага, фиксированные скидки, обработка экстравагантных запросов, отлизывание жопы, где-то даже бесплатно, полное доверие.
В какой-то момент, у постоянного клиента меняется менеджер. Прилетает очередная таска на доработку. Доработки сделаны, но менеджер визжит-пищит и орет — я просил другое!
По ТЗ все гладко, перепроверяют, как просили — так и сделали. Не доебаться!
Но нет, откуда-то берутся новые вводные. Новые вводные предварительно озвучены не были. Вводные в голове нового менеджера, которые он получил из космоса. То, что их нет в ТЗ, это сугубо личные проблемы исполнителя.
Кто виноват? Конечно — исполнитель! Он должен был догадаться сам. А значит виноват — исполнитель!
Исполнитель пробует решить всё миром, объясняет, так и так, что это дополнительные человеко-часы, в договоре такого нет, нужно доплатить и вообще так не делается.
По итогу — виноват исполнитель, переделывайте за свой счет.
Классика! Ну такое себе…
Что имеем: С таким менеджером дальше работать никто не будет, искать концы до главного босса тем более (других клиентов жопой ешь). Конфликт конечно же нужно уладить, спустить на тормозах. Мы же взрослые люди. Но на этом увы всё, сотрудничество закончено!
Да, у айтишников есть свой «черный список», который гуляет в приватных чатах в телеграм. Не только HRы этим грешат.
В таких ситуациях не стоит хамить, нужно разобраться и найти какие-то общие точки соприкосновений.
Искать правду и что-то доказывать смысла нет, если человек живет в своем мире, его от туда уже не вытащить. И нужно ли вытаскивать? Ему там комфортно, он таким уродился!
Не профессионально? Вопрос не корректный, тратить время на выяснения отношений себе дороже, дешевле распрощаться, проще освободить ресурс и взять нового клиента. Виз из Спарта!
Конфликт решается просто — ок, сделаем как вы хотите. Пусть думают что всё пошло по их правилам, но это лишь начало конца.
Это наглядный пример, как один менеджер способен за полчаса уничтожить протоптанные годами мосты сотрудничества.
Теперь сайтики и CI/CD, бывшему клиенту обойдутся в x2-x3 дороже, потому что рыночные цены ушагали вперед семимильными шагами, даже на фрилансе.
Мосты сожжены, а реквест на расторжение договора выслан по почте. Всё рамках трудовых отношений.
Подведем итоги:
Если у тебя свой бизнес, всегда контролируй основные звенья своего коллектива. Либо делегируй этот контроль проверенным людям.
Для ИПешников с сотрудниками это прям критично.
Но порой и проверенные люди тоже дают сбой (оказываются пидарасами), это как продакшен. Продакшен в 99% случаев тот еще пидарас.
Поэтому изредка сам вылазий из берлоги и проходись по всем процессам самостоятельно, узнаешь много нового и (интересного) хуевого.
Ну а если это твой основной заказчик (который делает тебе 90% прибыли), найди выходы на главного и обсуди все вопросы с ним, благо это делается на раз-два. Менеджер уйдет сразу нахуй и будет выкинут на улицу. Проходили, знаем.
Но лично я предпочитаю чтобы овнер сам это всё просек и нашел крысу. Без подсказок и т.п. Если не просекет, то извините, выше уже не прыгнет с такими кадрами.
Большего и не скажешь. Если читал книгу «Не работайте с мудаками» расскажи в паре слов, о чем она. А то всё руки не дойдут полистать.
Спасибо за внимание и до свидания!
—
Please open Telegram to view this post
VIEW IN TELEGRAM
5 68
This media is not supported in your browser
VIEW IN TELEGRAM
Про яйца и балансировщик нагрузки
Когда нужно распределить запросы между серверами, возникает проблема — а как блядь понять, какой сервер сейчас менее нагружен?
ㅤ
Постоянно опрашивать сервера, это хуйня, информация будет не актуальной, все это медленно, пока мы собирали данные, ситуация уже поменялась.
На этом фоне возникает эффект «стада», когда много запросов дружно бегут туда, где вроде бы свободно и по итогу перегружают сервер еще больше.
Это можно решить проще — например перенаправлять запросы случайно.
Работает это вроде неплохо, но опять же всегда есть шанс, что нагрузка будет неравномерной. И снова получаем, что какой-то из серверов будет перегружен запросами.
Какой-то замкнутый круг, печаль и говнище.
А чё делать?
Представь: я в рандоме выбираю два сервера, смотрю какой из них менее загружен и отправляю туда запросы. Все!
Вроде мелочь, но работает этот подход прям заебись! И что интересно у этого подхода есть официальная формулировка — Power of Two Choices или «Сила двух выборов».
Почему это заебись?
На просторах есть задачка «яйца и корзины», в оригинале там конечно не «яйца», а шары.
Короче. Мы случайно кидаем яйца в корзины. Если класть каждое яйцо в случайную корзину, то в итоге некоторые корзины будут переполнены.
Но если каждый раз выбирать две корзины и класть яйцо туда, где их меньше — ситуация резко улучшается.
Максимальная перегрузка корзины падает в разы. И это при том, что мы по-прежнему делаем случайный выбор, просто из двух вариантов, а не из одного.
Все просто! Тоже самое и с серверами:
- Если мы выбираем сервер наугад, нагрузка на сервер может стать критической.
- Если выбираем между двумя, вероятность перегрузить сервер падает квадратично.
Давай на котиках:
Представь, что у тебя есть куча серверов, и на четверти из них пришло по 4 запроса.
- Если я выбираю сервер случайно, есть 25% шанс попасть именно на сервер, которому уже пезда.
- Если я выбираю два сервера и беру менее загруженный — вероятность того, что оба окажутся с нагрузкой 4, уже всего 6,25% (1/16).
Получается, что вероятность перегрузки падает очень быстро. А дальше — ещё быстрее: чтобы нагрузка выросла до 5, 6 и так далее, нужно каждый раз «удачно» попасть в редкие перегруженные сервера, и шанс становится ничтожным.
Видишь, математика нужна не только бекендерам, но и в девопсе можно применить.
Что получаем на практике:
На практике балансировка «выбором из двух» делает распределение нагрузки по серверам почти равномерной. При этом мы не тратим кучу ресурсов на мониторинг и не пытаемся каждый раз точно узнать состояние всех серверов.
Такой подход - простой и элегантный. Как говорится — без хуйни!
Формулы и расчеты визуально можешь глянуть тут. Там как раз разбирается способ с яйцами, но уже с углубленной математикой и формулами.
Как реализовать в nginx
Вместо случайного выбора
Мотай на ус, глядишь сгодится в хозяйстве.
🛠 #devops #nginx
—
✅ @bashdays ✅ @linuxfactory ✅ @blog
Когда нужно распределить запросы между серверами, возникает проблема — а как блядь понять, какой сервер сейчас менее нагружен?
ㅤ
Постоянно опрашивать сервера, это хуйня, информация будет не актуальной, все это медленно, пока мы собирали данные, ситуация уже поменялась.
На этом фоне возникает эффект «стада», когда много запросов дружно бегут туда, где вроде бы свободно и по итогу перегружают сервер еще больше.
Это можно решить проще — например перенаправлять запросы случайно.
Работает это вроде неплохо, но опять же всегда есть шанс, что нагрузка будет неравномерной. И снова получаем, что какой-то из серверов будет перегружен запросами.
Какой-то замкнутый круг, печаль и говнище.
А чё делать?
Представь: я в рандоме выбираю два сервера, смотрю какой из них менее загружен и отправляю туда запросы. Все!
Вроде мелочь, но работает этот подход прям заебись! И что интересно у этого подхода есть официальная формулировка — Power of Two Choices или «Сила двух выборов».
Почему это заебись?
На просторах есть задачка «яйца и корзины», в оригинале там конечно не «яйца», а шары.
Короче. Мы случайно кидаем яйца в корзины. Если класть каждое яйцо в случайную корзину, то в итоге некоторые корзины будут переполнены.
Но если каждый раз выбирать две корзины и класть яйцо туда, где их меньше — ситуация резко улучшается.
Максимальная перегрузка корзины падает в разы. И это при том, что мы по-прежнему делаем случайный выбор, просто из двух вариантов, а не из одного.
Все просто! Тоже самое и с серверами:
- Если мы выбираем сервер наугад, нагрузка на сервер может стать критической.
- Если выбираем между двумя, вероятность перегрузить сервер падает квадратично.
Давай на котиках:
Представь, что у тебя есть куча серверов, и на четверти из них пришло по 4 запроса.
- Если я выбираю сервер случайно, есть 25% шанс попасть именно на сервер, которому уже пезда.
- Если я выбираю два сервера и беру менее загруженный — вероятность того, что оба окажутся с нагрузкой 4, уже всего 6,25% (1/16).
Получается, что вероятность перегрузки падает очень быстро. А дальше — ещё быстрее: чтобы нагрузка выросла до 5, 6 и так далее, нужно каждый раз «удачно» попасть в редкие перегруженные сервера, и шанс становится ничтожным.
Видишь, математика нужна не только бекендерам, но и в девопсе можно применить.
Что получаем на практике:
На практике балансировка «выбором из двух» делает распределение нагрузки по серверам почти равномерной. При этом мы не тратим кучу ресурсов на мониторинг и не пытаемся каждый раз точно узнать состояние всех серверов.
Такой подход - простой и элегантный. Как говорится — без хуйни!
Формулы и расчеты визуально можешь глянуть тут. Там как раз разбирается способ с яйцами, но уже с углубленной математикой и формулами.
Этот же принцип используют, например, в cuckoo hashing (структура данных для хранения ключей).
Cuckoo hashing (кукушкино хеширование) — алгоритм разрешения коллизий значений хеш-функций в таблице с постоянным временем выборки в худшем случае.
Как реализовать в nginx
upstream backend {
random two; # Power of 2 Choices
server app1.bashdays.ru;
server app2.bashdays.ru;
server app3.bashdays.ru;
}
Вместо случайного выбора
nginx
берёт два случайных сервера и кидает запрос на тот, где меньше соединений.Этот же принцип используют, например, в cuckoo hashing (структура данных для хранения ключей).
Мотай на ус, глядишь сгодится в хозяйстве.
—
Please open Telegram to view this post
VIEW IN TELEGRAM
7 84
Первый митап по инфраструктуре от Wildberries & Russ
2 октября, сбор участников с 18:00 | Москва и онлайн
В программе — всё самое интересное из мира инфраструктуры: от файловых хранилищ на экстремальных нагрузках до автоматизации репозиториев и философии DevOps.
Доклады:
- Файловое хранилище Wildberries: бескомпромиссный HighLoad | Иван Волков, CTO CDN
- Путь автоматизации репозиториев в Nexus | Владислав Раев, DevOps & DevTools Engineer
- У вас завелся сервис: рекомендации лучших сервисоводов (наверное) | Александр Стовбунский, Tools Team TechLead
Для участия в офлайне регистрация обязательна. После докладов — продуктивный нетворкинг и афтерпати.
Реклама. ООО «АРХИТЕКТОРЫ БУДУЩЕГО», ИНН: 3662286029, Erid: 2Vtzqw8AKb2
2 октября, сбор участников с 18:00 | Москва и онлайн
В программе — всё самое интересное из мира инфраструктуры: от файловых хранилищ на экстремальных нагрузках до автоматизации репозиториев и философии DevOps.
Доклады:
- Файловое хранилище Wildberries: бескомпромиссный HighLoad | Иван Волков, CTO CDN
- Путь автоматизации репозиториев в Nexus | Владислав Раев, DevOps & DevTools Engineer
- У вас завелся сервис: рекомендации лучших сервисоводов (наверное) | Александр Стовбунский, Tools Team TechLead
Для участия в офлайне регистрация обязательна. После докладов — продуктивный нетворкинг и афтерпати.
Реклама. ООО «АРХИТЕКТОРЫ БУДУЩЕГО», ИНН: 3662286029, Erid: 2Vtzqw8AKb2
Как не стремись к автоматизации, всегда найдется какой-нибудь легаси сервис, который требует ручного обслуживания.
Был у меня такой сервис и работал он только тогда, когда все его файлы и каталоги принадлежали определенному пользователю.
ㅤ
Доступ к сервису имели многие, поэтому люди порой троили и запускали команды в каталоге сервиса от root. Сервису было на это поебать, но до момента его перезапуска.
Обычно это чинилось очень легко, через
Казалось бы, есть масса способов предотвратить такие ошибки: правильные права на файлы, ACL’ы, SELinux.
Но веселья в этом мало! Поэтому я решил заебенить свой собственный мониторинг файловой системы. Скиллов то предостаточно, хули нет.
Спойлер:Я залез в кроличью нору и знатно так хлебнул гавна.
Попытка намбер 1
В Linux есть API под названием fanotify, с его помощью можно получать события о действиях с файлами в юзерспейс.
Всё просто: инициализируем fanotify_init, указываем каталоги через fanotify_mark и читаем события из дескриптора.
Но тут же вылез огромный хуй:
- нельзя отслеживать каталоги рекурсивно (только целый маунт)
-
Решение вполне рабочее, но громоздкое. Я такие не люблю, этож думать надо, вайбкодингом не решается.
Попытка намбер 2
Вспоминаем что есть
В
То есть единая точка входа. Там можно отлавливать события и фильтровать их, не гоняя лишние переключения контекста.
Но и тут вылез хуй:
-
- фильтрацию приходится писать прямо в
Да блядь…
Как я победил рекурсивный обход
Чтобы понять, что именно меняется в каталоге сервиса, пришлось использовать структуру
Но так как в
На практике этого вполне достаточно. Глубина каталогов мне известна. Ну и конечно, пришлось аккуратно работать с RCU-локами, чтобы дерево не поменялось в момент обхода.
Как можно улучшить
В идеале использовать не VFS-хуки, а LSM hooks (Linux Security Module).
Они стабильнее, понятнее и позволяют сразу работать с путями. Там можно красиво получить path и сразу преобразовать его в строку, а потом делать поиск подстроки.
Но в моём ядре этих хуков не было, хуй знает почему, видимо дистрибутив слишком древний. Надо попробовать на новых, чем черт не шутит.
Итоги
Эта поделка как и предполагалась, погрузила меня в печаль, душевные страдания, НО стала отличным тренажером для прокачки:
- Внутренностей Linux ядра
- Работы с eBPF
- И кучу другого с kernel-space
Информации по нему много, но вся она разбросана. Собрать всё это в кучу было отдельным квестом.
Мораль?
Иногда самое простое решение — это
🛠 #linux #debug #dev
—
✅ @bashdays ✅ @linuxfactory ✅ @blog
Был у меня такой сервис и работал он только тогда, когда все его файлы и каталоги принадлежали определенному пользователю.
ㅤ
Доступ к сервису имели многие, поэтому люди порой троили и запускали команды в каталоге сервиса от root. Сервису было на это поебать, но до момента его перезапуска.
Обычно это чинилось очень легко, через
chown -R
. Все это знали и никого это не смущало. Короче костыль ебаный.Казалось бы, есть масса способов предотвратить такие ошибки: правильные права на файлы, ACL’ы, SELinux.
Но веселья в этом мало! Поэтому я решил заебенить свой собственный мониторинг файловой системы. Скиллов то предостаточно, хули нет.
Спойлер:
Попытка намбер 1
В Linux есть API под названием fanotify, с его помощью можно получать события о действиях с файлами в юзерспейс.
Всё просто: инициализируем fanotify_init, указываем каталоги через fanotify_mark и читаем события из дескриптора.
Но тут же вылез огромный хуй:
- нельзя отслеживать каталоги рекурсивно (только целый маунт)
-
anotify
даёт только PID процесса, который что-то сделал. А чтобы узнать UID/GID — нужно лезть в /proc/<pid>/status
. То есть на каждое событие приходится открывать и парсить файлы в /proc
.Решение вполне рабочее, но громоздкое. Я такие не люблю, этож думать надо, вайбкодингом не решается.
Попытка намбер 2
Вспоминаем что есть
eBPF
. Это штука позволяет запускать программы прямо в ядре Linux. Они компилируются в байткод, проходят проверку, а потом гоняются через JIT почти с нативной скоростью.Что такое eBPF можешь почитать тут и тут.
В
eBPF
заебись то, что можно цепляться за разные функции ядра. Например, можно подцепиться к vfs_mkdir
или vfs_create
— это общий слой для работы с файлами.То есть единая точка входа. Там можно отлавливать события и фильтровать их, не гоняя лишние переключения контекста.
Но и тут вылез хуй:
-
kprobes
на функции VFS нестабильны, в новых ядрах сигнатуры могут меняться или функции вообще исчезнуть.- фильтрацию приходится писать прямо в
eBPF
, а там свои ограничения. Нет бесконечных циклов, стек всего ~512 байт.Да блядь…
Как я победил рекурсивный обход
Чтобы понять, что именно меняется в каталоге сервиса, пришлось использовать структуру
dentry
и подниматься по дереву до родителя.Но так как в
eBPF
нельзя сделать «бесконечный» цикл, я ограничил глубину с помощью MAX_DEPTH
.На практике этого вполне достаточно. Глубина каталогов мне известна. Ну и конечно, пришлось аккуратно работать с RCU-локами, чтобы дерево не поменялось в момент обхода.
➡️ Кусок кода в первом комментарии, сюда не влез.
Как можно улучшить
В идеале использовать не VFS-хуки, а LSM hooks (Linux Security Module).
Они стабильнее, понятнее и позволяют сразу работать с путями. Там можно красиво получить path и сразу преобразовать его в строку, а потом делать поиск подстроки.
Но в моём ядре этих хуков не было, хуй знает почему, видимо дистрибутив слишком древний. Надо попробовать на новых, чем черт не шутит.
Итоги
Эта поделка как и предполагалась, погрузила меня в печаль, душевные страдания, НО стала отличным тренажером для прокачки:
- Внутренностей Linux ядра
- Работы с eBPF
- И кучу другого с kernel-space
eBPF — мощнейший инструмент, но очень тонкий. Ошибёшься — будешь выебан в жопу.
Информации по нему много, но вся она разбросана. Собрать всё это в кучу было отдельным квестом.
Мораль?
Иногда самое простое решение — это
chown -R
. Но куда интереснее — написать свой велосипед и заглянуть в кроличью нору Linux ядра.—
Please open Telegram to view this post
VIEW IN TELEGRAM
9 42
Настройка core dump в Docker
Цель этого поста — дать тебе общее руководство по включению и сбору core dumps для приложений, работающих в docker контейнере.
Настраиваем хост для сохранения дампов
Для начала надо сконфигурировать хостовую машину, чтобы сохранять такие дампы в нужное место. Нет, не в жопу.
ㅤ
Универсальный способ — задать шаблон core pattern. Шаблон определяет путь и информацию о процессе который наебнулся.
Кратенько:
Как вариант, можно настроить host изнутри контейнера через CMD или ENTRYPOINT. Но контейнер в этом случае должен запускаться в privileged mode, что хуева с точки зрения безопасности.
Пример хуёвого приложения
После компиляции и запуска, приложение наебнется с ошибкой.
Пишем Dockerfile для этого приложения
Запускаем контейнер с нужными опциями:
Разбираем опции:
Здесь важно: путь
После того как приложение наебнется, core dump будет сохранён на хостовой машине в директории
Анализируем дамп с помощью gdb
Такс, мы получили core dump и он у нас лежит на хостовой машине, но рекомендуется открыть его внутри контейнера. Контейнер должен быть из того же образа, в котором компилилось приложение.
Это поможет убедиться, что все зависимости (библиотеки и прочая хуитень) доступны.
Если в образе нет исходного кода, можно допом смаунтить исходники:
Теперь внутри контейнера запускаем:
После загрузки дампа можно выполнить команду
Команда поможет определить, где именно произошел факап.
Давай быстренько разберем ошибку.
В исходнике было:
То есть ошибка здесь не баг компиляции или рантайма, а намеренно вставленный вызов
Если у тебя docker-compose, то все флаги (
Хуй знает чё еще написать, завтра тему дебага продолжим, чет в конце года много траблшутинга навалило разнообразного.
🛠 #linux #debug #dev
—
✅ @bashdays ✅ @linuxfactory ✅ @blog
Цель этого поста — дать тебе общее руководство по включению и сбору core dumps для приложений, работающих в docker контейнере.
Настраиваем хост для сохранения дампов
Для начала надо сконфигурировать хостовую машину, чтобы сохранять такие дампы в нужное место. Нет, не в жопу.
ㅤ
Универсальный способ — задать шаблон core pattern. Шаблон определяет путь и информацию о процессе который наебнулся.
echo '/tmp/core.%e.%p' | sudo tee /proc/sys/kernel/core_pattern
Кратенько:
%e
— имя процесса %p
— pid процессаБолее подробно о конфигурации core pattern можешь почитать в man-странице ядра Linux.
Как вариант, можно настроить host изнутри контейнера через CMD или ENTRYPOINT. Но контейнер в этом случае должен запускаться в privileged mode, что хуева с точки зрения безопасности.
Пример хуёвого приложения
#include <cstdlib>
void foo() {
std::abort();
}
int main() {
foo();
return 0;
}
После компиляции и запуска, приложение наебнется с ошибкой.
Пишем Dockerfile для этого приложения
FROM ubuntu:22.04
# Install tools
RUN apt update \
&& apt -y install \
build-essential \
gdb \
&& rm -rf /var/lib/apt/lists/*
# Build the application
COPY ./ /src/
WORKDIR /src/
RUN g++ main.cpp -o app
CMD ["/src/app"]
Тот кто в теме, сможет его прочитать и понять. Если не понятно, гугли и разбирай, качнешь свой девопсовый скиллз.
Запускаем контейнер с нужными опциями:
docker run \
--init \
--ulimit core=-1 \
--mount type=bind,source=/tmp/,target=/tmp/ \
application:latest
Разбираем опции:
--init
— гарантирует корректную обработку сигналов внутри контейнера--ulimit
— устанавливает неограниченный размер core dump для процессов внутри контейнера--mount
— монтирует /tmp
из хоста в контейнер, чтобы дампы, создаваемые внутри контейнера, были доступны после его остановки или удаленияЗдесь важно: путь
source
на хосте должен совпадать с тем, который задан в шаблоне core pattern.После того как приложение наебнется, core dump будет сохранён на хостовой машине в директории
/tmp
. ls /tmp/core*
# /tmp/core.app.5
Анализируем дамп с помощью gdb
Такс, мы получили core dump и он у нас лежит на хостовой машине, но рекомендуется открыть его внутри контейнера. Контейнер должен быть из того же образа, в котором компилилось приложение.
Это поможет убедиться, что все зависимости (библиотеки и прочая хуитень) доступны.
docker run \
-it \
--mount type=bind,source=/tmp/,target=/tmp/ \
application:latest \
bash
Если в образе нет исходного кода, можно допом смаунтить исходники:
docker run \
-it \
--mount type=bind,source=/tmp/,target=/tmp/ \
--mount type=bind,source=<путь_к_исходникам_на_хосте>,target=/src/ \
application:latest \
bash
Теперь внутри контейнера запускаем:
gdb app /tmp/core.app.5
После загрузки дампа можно выполнить команду
bt
(backtrace), чтобы увидеть трассировку стека:(gdb) bt
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1 0x00007f263f378921 in __GI_abort () at abort.c:79
#2 0x000055f9a9d16653 in foo() ()
#3 0x000055f9a9d1665c in main ()
Команда поможет определить, где именно произошел факап.
Давай быстренько разберем ошибку.
#0
и #1
показывают, что процесс получил сигнал 6 (SIGABRT) и завершился через abort()
#2
— вызов произошёл внутри функции foo()
#3
— main()
вызвал foo()
В исходнике было:
void foo() {
std::abort();
}
То есть ошибка здесь не баг компиляции или рантайма, а намеренно вставленный вызов
std::abort()
, который и приводит к аварийному завершению и генерации core dump.Если у тебя docker-compose, то все флаги (
--init
, --ulimit
, --mount
и т.д.) применимы и для него. То есть отладку можно легко адаптировать.Хуй знает чё еще написать, завтра тему дебага продолжим, чет в конце года много траблшутинга навалило разнообразного.
—
Please open Telegram to view this post
VIEW IN TELEGRAM
5 42
Чем глубже пропасть, в которую падаешь, тем больше шансов научиться летать.
На подходе новый закон о глобальном запрете мата в сети, поэтому к нему нужно подготовиться. Переебашивать каждый пост в блоге — проблематично, да и лень.
ㅤ
Поэтому, как обычно, будем изобретать велосипед.
Суть идеи — налету в DOM менять маты на синонимы. То есть в момент отдачи контента, контент будет насильно зацензурен.
А там уже можно будет добавить регулярки и гибко всё затюнить, мало ли, может можно будет звездочками разбавлять такой контент.
Реализация
За основу я возьму angie (форк nginx) с модулем LUA. Я давно на это решение пересел, так как всё из коробки работает, включая генерацию SSL. Не нужно ебстись с компиляций модулей и страдать.
Если LUA не установлен, ставим:
В
В
Ну и создаем файл
Проверяем:
Открываем сайт и видим что все маты зацензурились согласно шаблону в файле
Если всё осталось по-прежнему, скинь кеш, в 99% дело в нем.
Давай разберемся как это работает.
И получаем — блок берёт HTML-страницу, проходит по каждому чанку тела ответа, и заменяет в нём «запрещённые» слова из словаря на синонимы.
Ааа, еще в словаре
Любая буква, цифра или подчёркивание (
Поэтому лучше сделать как-то так:
LUA — сила! Рекомендую хоть раз потыкать, проникнешься и уже не сможешь без этого модуля жить. Костыли клепать милое дело.
Как вариант, позже еще запилю «специальный» заголовок, при передаче которого angie будет отключать цензуру и выводить посты в оригинале.
Ну заебись же! Осталось придумать, как зацензурить 1000 постов в телеге.
🛠 #angie #nginx #tricks
—
✅ @bashdays ✅ @linuxfactory ✅ @blog
На подходе новый закон о глобальном запрете мата в сети, поэтому к нему нужно подготовиться. Переебашивать каждый пост в блоге — проблематично, да и лень.
ㅤ
Поэтому, как обычно, будем изобретать велосипед.
Суть идеи — налету в DOM менять маты на синонимы. То есть в момент отдачи контента, контент будет насильно зацензурен.
Хуйня == Фигня, Пезда == 3.14зда ну и в таком духе.
А там уже можно будет добавить регулярки и гибко всё затюнить, мало ли, может можно будет звездочками разбавлять такой контент.
Реализация
За основу я возьму angie (форк nginx) с модулем LUA. Я давно на это решение пересел, так как всё из коробки работает, включая генерацию SSL. Не нужно ебстись с компиляций модулей и страдать.
Как настроить автополучение SSL в angie, писал в этом посте.
Если LUA не установлен, ставим:
apt install angie-module-lua
В
/etc/angie/angie.conf
добавляем:load_module modules/ndk_http_module.so;
load_module modules/ngx_http_lua_module.so;
load_module modules/ngx_stream_lua_module.so;
В
/etc/angie/sites-available/bashdays.ru.conf
добавляем в корневой локейшен:location / {
root /var/www/bashdays.ru/htdocs;
index index.html;
gzip off;
body_filter_by_lua_block {
local replacements = dofile("/etc/angie/wordmap.lua")
local chunk = ngx.arg[1]
if chunk then
for _, pair in ipairs(replacements) do
chunk = ngx.re.gsub(chunk, pair[1], pair[2], "ijo")
end
ngx.arg[1] = chunk
end
}
}
Ну и создаем файл
/etc/angie/wordmap.lua
который будет содержать шаблоны замены:return {
{"хуйня", "фигня"},
{"хуй", "писька"},
{"говн%w*", "ерунда"},
{"еба%w*", "плохой"},
}
Проверяем:
angie -t
и если всё ок, можно сделать systemctl restart angie
.Открываем сайт и видим что все маты зацензурились согласно шаблону в файле
/etc/angie/wordmap.lua
.Если всё осталось по-прежнему, скинь кеш, в 99% дело в нем.
Давай разберемся как это работает.
body_filter_by_lua_block
— перед отправкой ответа клиенту, запустится Lua-скрипт, который изменит тело ответа.dofile("/etc/angie/wordmap.lua")
— загружает Lua-файл со словарём замен.ngx.arg[1]
— текущий кусок (chunk) ответа (HTML, JSON и т.п.), который angie собирается отправить клиенту. Ответ приходит потоками.for _, pair in ipairs(replacements)
— перебор всех замен из словаря.ngx.re.gsub(chunk, pair[1], pair[2], "ijo")
— регулярная замена, [1]
что искать, [2]
на что заменить."ijo"
— флаги: i
— без учёта регистра, j
— dotall (точка матчится на \n
), o
— оптимизация.ngx.arg[1] = chunk
— возвращаем изменённый кусок, который уйдёт клиенту.И получаем — блок берёт HTML-страницу, проходит по каждому чанку тела ответа, и заменяет в нём «запрещённые» слова из словаря на синонимы.
Ааа, еще в словаре
{"говн%w*", "ерунда"}
есть символы %w*
это регулярка. Любая буква, цифра или подчёркивание (
[0-9A-Za-z_]
). В UTF-8 оно обычно ловит только латиницу, а кириллицу нет.Поэтому лучше сделать как-то так:
{"говн[А-Яа-яЁё]*", "ерунда"}
. Короче тут тебе карты в руки, сам натыкай паттерны.LUA — сила! Рекомендую хоть раз потыкать, проникнешься и уже не сможешь без этого модуля жить. Костыли клепать милое дело.
Есть конечно нюансы, например — Если слово вдруг разорвётся между чанками (например, ху в одном чанке и йня в другом) — фильтр его не заменит. Для надёжности нужно буферизовать весь ответ.
Ну и с кириллицей надо вопрос дофиксить, но это я реализую чуть позже. Главное концепт. Всё остальное реализуемо.
Как вариант, позже еще запилю «специальный» заголовок, при передаче которого angie будет отключать цензуру и выводить посты в оригинале.
А можно разработчиков подъебать, пусть ищут в своем коде, почему у них слова странным образом заменяются.
Ну заебись же! Осталось придумать, как зацензурить 1000 постов в телеге.
—
Please open Telegram to view this post
VIEW IN TELEGRAM
13 48
Быть в тренде = быть на DevOps Meetup по Platform Engineering! ⚙️
Платформенный подход — новый тренд в IT, и кто первый его подхватит — тот сможет масштабироваться, ускорить и улучшить разработку, без потери контроля и безопасности.
🎤 На митапе спикеры из Сбера, Т-Банка и Cloud․ru поделятся практическим и честным опытом внедрения Platform Engineering.
📍 Москва, офис Сбера
⏰ 6 октября, 18:30
👉 Онлайн+офлайн
Регистрируйся по ссылке.
Платформенный подход — новый тренд в IT, и кто первый его подхватит — тот сможет масштабироваться, ускорить и улучшить разработку, без потери контроля и безопасности.
🎤 На митапе спикеры из Сбера, Т-Банка и Cloud․ru поделятся практическим и честным опытом внедрения Platform Engineering.
📍 Москва, офис Сбера
⏰ 6 октября, 18:30
👉 Онлайн+офлайн
Регистрируйся по ссылке.
Сегодня коллега, который проводит дохрена технический собесов поделился инсайдом. Мол кандидаты из Южной Америки часто называют временные переменные
ㅤ
Прикольно. Для меня
А в чем дело-то?
Причины могут быть в языке и в традициях обучения.
Южная Америка и «aux»
Во многих странах Латинской Америки (а также в Испании и Португалии) обучение программированию ведётся на родном языке.
Слово
Поэтому сокращение
Восточная Европа и «temp»
В странах Восточной Европы (Россия, Польша и др.) учебные материалы часто брались с английских источников или напрямую переводились, но при этом терминология частично сохранялась.
В англоязычных книгах традиционное имя временной переменной —
Ещё один фактор — русскоязычные (и в целом восточноевропейские) программисты исторически чаще учились по книгам на английском, чем по локализованным методичкам. Хотя и методичек особо таких и не было.
Давай разберем другие страны
Китай
- В учебниках и коде часто встречается
-
- Булевые переменные часто называются
- Комментарии «中英混合» — смесь китайских и английских терминов:
- В олимпиадном коде часто встречается
Западная Европа / США
- Стандартные учебные названия:
- В учебниках на джава и питоне для временных значений часто используют
- В научном и численном коде — переменные
Ну тут классика, аналогично Мистер и Миссис Стоговы из учебников по инглишу.
Восточная Европа / Россия
-
-
-
Переменные
Комментарии часто начинаются с
Ближний Восток
- В арабоязычных странах иногда встречается
- Комментарии миксуют латиницу и арабицу, например:
Индия
-
- В комментариях любят писать
Названия переменных иногда из «хинди-английского микса» в учебных проектах:
В целом получаем:
- Испаноязычные/португалоязычные —
- Восточная Европа —
- Англоязычные —
- Китай/Индия —
Короче вся это тема — маленькие «акценты» кода. Про 1Сников писать уж не буду, сами все знаете как они переменные называют.
Не смею больше отвлекать, хороших тебе выходных!
🛠 #рабочиебудни #dev
—
✅ @bashdays ✅ @linuxfactory ✅ @blog
aux
, а вот кандидаты из Восточной Европы - temp
. Такая вот этнография.ㅤ
Прикольно. Для меня
aux
это дырка в которую можно что-то вставить.А в чем дело-то?
Причины могут быть в языке и в традициях обучения.
Южная Америка и «aux»
Во многих странах Латинской Америки (а также в Испании и Португалии) обучение программированию ведётся на родном языке.
Слово
auxiliar
(испанское) или auxiliar/auxiliaridade
(португальское) переводится как «вспомогательный». Поэтому сокращение
aux
— это естественный выбор для временной переменной. Многие учебники и преподаватели прямо используют aux
в примерах.Восточная Европа и «temp»
В странах Восточной Европы (Россия, Польша и др.) учебные материалы часто брались с английских источников или напрямую переводились, но при этом терминология частично сохранялась.
В англоязычных книгах традиционное имя временной переменной —
temp
(от temporary
). В итоге это закрепилось как привычка.Ещё один фактор — русскоязычные (и в целом восточноевропейские) программисты исторически чаще учились по книгам на английском, чем по локализованным методичкам. Хотя и методичек особо таких и не было.
То есть это, по сути, отражение того, на каком языке преподавали первые курсы информатики и какие примеры попадались студентам.
Такие мелочи могут «маркировать» культурный бэкграунд разработчика не хуже акцента в речи.
Давай разберем другие страны
Китай
- В учебниках и коде часто встречается
tmp
(это короче чем temp
).-
arr
почти всегда вместо array
.- Булевые переменные часто называются
flag
.- Комментарии «中英混合» — смесь китайских и английских терминов:
// 计算 sum
total = total + arr[i];
- В олимпиадном коде часто встречается
ans
и vis
(visited).Западная Европа / США
- Стандартные учебные названия:
temp
, foo
, bar
, baz
.- В учебниках на джава и питоне для временных значений часто используют
value
или val
.- В научном и численном коде — переменные
x
, y
, z
, dx
, dy
(от физики и математики).Ну тут классика, аналогично Мистер и Миссис Стоговы из учебников по инглишу.
Восточная Европа / Россия
-
temp
как временная переменная (от англ. temporary).-
buf
вместо buffer
(сильно закрепилось ещё с ассемблеров и C-шных примеров).-
cnt
для счётчиков (counter) — иногда даже вместо i/j/k
.Переменные
res
(result) и ans
(answer) очень популярны в олимпиадном программировании.Комментарии часто начинаются с
// !!!
или // FIXME:
на смеси русского и английского.Ближний Восток
- В арабоязычных странах иногда встречается
mosa3ed
(مساعد = помощник), но чаще используют англоязычные temp/aux
.- Комментарии миксуют латиницу и арабицу, например:
// calculate المجموع
// check if الشرط
// temp متغير
Индия
-
temp
тоже стандарт, но часто встречается flag
для булевых переменных (очень широко).- В комментариях любят писать
// logic
или // main logic
, даже если код очевиден.Названия переменных иногда из «хинди-английского микса» в учебных проектах:
num1
, chotu
(маленький), bada
(большой).В целом получаем:
- Испаноязычные/португалоязычные —
aux
.- Восточная Европа —
temp/buf/cnt/res
.- Англоязычные —
temp/foo/bar
.- Китай/Индия —
tmp/flag/arr/ans
.Короче вся это тема — маленькие «акценты» кода. Про 1Сников писать уж не буду, сами все знаете как они переменные называют.
Не смею больше отвлекать, хороших тебе выходных!
—
Please open Telegram to view this post
VIEW IN TELEGRAM
8 69
Привет друзья, Масим Братковский запилил для нас техническую статейку.
ㅤ
Сюда по классике не влезло, опубликовал в блоге. Идем читать.
Что делать если postman достал, а надо тестировать SOAP API.
Комментарий автора: Если вам интересно, давайте обратную связь, буду рад продолжить серию статей.
🛠 #dev #qa
—
✅ @bashdays ✅ @linuxfactory ✅ @blog
ㅤ
Сюда по классике не влезло, опубликовал в блоге. Идем читать.
Что делать если postman достал, а надо тестировать SOAP API.
Комментарий автора: Если вам интересно, давайте обратную связь, буду рад продолжить серию статей.
—
Please open Telegram to view this post
VIEW IN TELEGRAM
Привет, очередная халява. Каждый год я отдаю 3 проходки-билета (скидка 100%) на онлайн-конференцию «Подлодка».
Если есть желание посетить сие онлайн-мероприятие, кликай кнопку ниже. Через пару дней опубликуются результаты. Ну а дальше с вами свяжется я или Макс и раздадим ништяки. Такие дела!
Условия розыгрыша: подписаться на канал @bashdays, @gitgate, @devopsina
Если есть желание посетить сие онлайн-мероприятие, кликай кнопку ниже. Через пару дней опубликуются результаты. Ну а дальше с вами свяжется я или Макс и раздадим ништяки. Такие дела!
Условия розыгрыша: подписаться на канал @bashdays, @gitgate, @devopsina
1 16
Bash Days | Linux | DevOps
Привет, очередная халява. Каждый год я отдаю 3 проходки-билета (скидка 100%) на онлайн-конференцию «Подлодка». Если есть желание посетить сие онлайн-мероприятие, кликай кнопку ниже. Через пару дней опубликуются результаты. Ну а дальше с вами свяжется я или…
1. Jull (@sun_jumper)
2. Алексей (@hapy_hex)
3. Александр (@khodzh97)
Please open Telegram to view this post
VIEW IN TELEGRAM
Здесь: я как-то поднимал проблему с торможением 1c на postgres.
🔤 🔤 🔥 🔤 🔤 🔤 🔤
Благодаря нашему коллеге @ovchinnikovmy, дело сдвинулось с мертвой точки. Спасибо ему большое за консультации и рекомендации по PG.
ㅤ
Мы начали попытки оптимизировать работу postgres для нашей задачи. И сразу столкнулись с проблемой. Ну, оптимизировали. А насколько?
Улучшение есть, а кто был виноват в тормозах PG или 1С?
Все может прекрасно работать в тестах, и становится колом, когда идет интенсивная работа в нескольких базах одновременно. Где горлышко бутылки - число ядер, частота или скорость диска, или может пора памяти добавить?
Там маленькая конторка. Фактически один сервак. Не будешь же zabbix ради этого ставить.
Онлайн можно посмотреть через
Остановился на пакете
Он собирает статистику каждые 10 сек по двум пользователям postgres (PG) и usr1cv83 (1С) в csv-лог (разделитель пробел, но это можно исправить).
Поскольку лог текстовый, дальше его можно вертеть с помощью awk/sort или просто в LibreOffice Calc.
pidstat ключи:
-r - память
-l - командная строка процесса
-d - диск
-h - табличный режим
-H - время unix
-U - username
-u - проц
gawk ключи:
🛠 #debug #linux
—
✅ @bashdays ✅ @linuxfactory ✅ @blog
Благодаря нашему коллеге @ovchinnikovmy, дело сдвинулось с мертвой точки. Спасибо ему большое за консультации и рекомендации по PG.
ㅤ
Мы начали попытки оптимизировать работу postgres для нашей задачи. И сразу столкнулись с проблемой. Ну, оптимизировали. А насколько?
Улучшение есть, а кто был виноват в тормозах PG или 1С?
Все может прекрасно работать в тестах, и становится колом, когда идет интенсивная работа в нескольких базах одновременно. Где горлышко бутылки - число ядер, частота или скорость диска, или может пора памяти добавить?
Там маленькая конторка. Фактически один сервак. Не будешь же zabbix ради этого ставить.
Онлайн можно посмотреть через
nmon, top/htop
. nmon
даже позволяет записывать данные в лог, и есть программа, которая позволяет генерить html с отчетами, но там все интегрально. По системе. А хочется по процессам.Остановился на пакете
sysstat
. Это такой консольный zabbix. Он позволяет собирать статистику по процессам. Анализировать можно память, проц, диск, стэк. Причем по каждому PID в отдельности и прямо в консоли. В общем, все, что нужно. Для большего удобства я набросал скрипт.#!/bin/bash
# 20251005
# apt install sysstat gawk
# работа с 9 до 18, запись с 8:30 до 18:30
# запуск через cron
# 30 8 * * * /root/work/stat/stat.sh &
declare -x PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
declare -i INTERVAL_SEC=10
declare -i COUNT=3600 # итого 10 часов
declare -i WEEK_DAY;printf -v WEEK_DAY "%(%-u)T"
declare LOG="$0_${WEEK_DAY}.csv"
pidstat -r -l -d -H -h -U -u $INTERVAL_SEC $COUNT |
gawk 'NR<4;$2=="usr1cv83"||$2=="postgres"{$1=strftime("%Y%m%d_%H%M%S",$1);print}'>"$LOG"
Он собирает статистику каждые 10 сек по двум пользователям postgres (PG) и usr1cv83 (1С) в csv-лог (разделитель пробел, но это можно исправить).
Поскольку лог текстовый, дальше его можно вертеть с помощью awk/sort или просто в LibreOffice Calc.
pidstat ключи:
-r - память
-l - командная строка процесса
-d - диск
-h - табличный режим
-H - время unix
-U - username
-u - проц
gawk ключи:
NR<4
- заголовок (легенда) из трех строк$2=="usr1cv83"||$2=="postgres"
- фильтрация по username$1=strftime("%Y%m%d_%H%M%S",$1)
- удобный формат времени.LOG="$0_${WEEK_DAY}.csv"
- Недельная ротация. По одному на день.—
Please open Telegram to view this post
VIEW IN TELEGRAM
Много шума наделала метка A+. Как оказалось эта иконка очень страшная для «тревожных».
ㅤ
А «страшная» она тем, что в интернетах нагнали жути, мол тотальная слежка, слив данных и т.п. Сейчас я тебе расскажу правду, что происходит.
Яж всегда с тобой был честен.
1 ноября 2024 года в силу вступил закон, об обязательной регистрации блогеров, у которых > 10к подписчиков. Все блогеры были обязаны пойти в РКН и зарегистрировать свои каналы, группы, площадки. Отдав взамен свои номера телефонов, явки и пароли.
Если этого не сделать, нельзя размещать партнерские посты, из таких каналов нельзя делать репосты. То есть если ты делаешь репост из такого канала, который не зарегистрирован в РКН — ты нарушаешь закон.
Чтобы тебя за жопу не взяли, я сделал все как требуется, все по правилам. Теперь ты можешь репостить и делиться этим с коллегами. Обезопасил твою задницу.
Под эту тему все мы пошли и зарегистрировались в РКН, да, еще в 2024 году. В описании каналов и групп ты мог видеть ссылку на сайт госуслуг, который это подтверждает. Но большинство на это не обратило внимания. Зря.
Я к чему, почти год ты сидишь в таких каналах и с удовольствием поглощаешь контент. А как только увидел A+ — бежать! Ничего же не изменилось, все что нужно, про тебя и так все давно уже знают.
К 2026 году 99% площадок будут ходить с этой меткой, чтобы следовать закону, чтобы была возможность размещать партнерские посты и как-то конвертировать полезный контент в хлеб с маслом.
Так что не ссы, если хочешь быть в безопасности — отключи у себя интернет, выкинь телефон и завернись в фольгу. Ну и обязательно почитай матчасть как все это работает изнутри.
Для тебя ничего не изменилось. А для меня изменилось, стало больше геморроя с отчетностью, с дополнительными налогами и т.п. Но так или иначе я продолжу делать своё дело и буду делать его хорошо.
Поэтому не устраивай бои с тенью и не будь «тревожным». Если живешь правильно и прозрачно, никто за тобой следить не будет. Не руби с плеча, разберись и думай своей головой, а не головкой персонажа, который нагнал на тебя жути в каких-то пабликах.
Как-то так. Мотай на ус. Всех обнял!
🛠 #рабочиебудни
—
✅ @bashdays ✅ @linuxfactory ✅ @blog
ㅤ
А «страшная» она тем, что в интернетах нагнали жути, мол тотальная слежка, слив данных и т.п. Сейчас я тебе расскажу правду, что происходит.
Яж всегда с тобой был честен.
1 ноября 2024 года в силу вступил закон, об обязательной регистрации блогеров, у которых > 10к подписчиков. Все блогеры были обязаны пойти в РКН и зарегистрировать свои каналы, группы, площадки. Отдав взамен свои номера телефонов, явки и пароли.
Если этого не сделать, нельзя размещать партнерские посты, из таких каналов нельзя делать репосты. То есть если ты делаешь репост из такого канала, который не зарегистрирован в РКН — ты нарушаешь закон.
А сколько раз ты нарушил закон и репостнул из таких каналов мемчики?
Чтобы тебя за жопу не взяли, я сделал все как требуется, все по правилам. Теперь ты можешь репостить и делиться этим с коллегами. Обезопасил твою задницу.
Под эту тему все мы пошли и зарегистрировались в РКН, да, еще в 2024 году. В описании каналов и групп ты мог видеть ссылку на сайт госуслуг, который это подтверждает. Но большинство на это не обратило внимания. Зря.
Я к чему, почти год ты сидишь в таких каналах и с удовольствием поглощаешь контент. А как только увидел A+ — бежать! Ничего же не изменилось, все что нужно, про тебя и так все давно уже знают.
К 2026 году 99% площадок будут ходить с этой меткой, чтобы следовать закону, чтобы была возможность размещать партнерские посты и как-то конвертировать полезный контент в хлеб с маслом.
Так что не ссы, если хочешь быть в безопасности — отключи у себя интернет, выкинь телефон и завернись в фольгу. Ну и обязательно почитай матчасть как все это работает изнутри.
Для тебя ничего не изменилось. А для меня изменилось, стало больше геморроя с отчетностью, с дополнительными налогами и т.п. Но так или иначе я продолжу делать своё дело и буду делать его хорошо.
Поэтому не устраивай бои с тенью и не будь «тревожным». Если живешь правильно и прозрачно, никто за тобой следить не будет. Не руби с плеча, разберись и думай своей головой, а не головкой персонажа, который нагнал на тебя жути в каких-то пабликах.
Как-то так. Мотай на ус. Всех обнял!
—
Please open Telegram to view this post
VIEW IN TELEGRAM
34 100
Сейчас я тебе покажу как «пиздато» организовать избранное в телеге.
У меня оно начиналось как «личное избранное», теперь это стало что-то вроде CRM внутри компании. Каждый сотрудник имеет к такой группе доступ и может закинуть туда что-то своё.
ㅤ
Этакая база данных всяких полезных фич.
Делается это банально. Создаешь приватную группу, включаешь в группе «топики», создаешь нужные топики. Всё!
По необходимости добавляешь в группу людей, либо чисто используешь под свои цели.
На скрине я создал тестовую группу, чтобы показать, как это визуально выглядит (реальную не стал закидывать, чтобы тебя не шокировать письками).
В реалиях у нас эта группа имеет овер 20 топиков, для бухов, для креативщиков, для личных целей и многое другое.
Кто-то посмотрел интересный фильм или увидел шортс который можно сконвертировать во что-то полезное — кидают это в топик.
У меня например там есть топик - Гитара, если натыкаюсь на что-то интересное, сохраняю туда. Потом когда появляется желание что-то изучить новое, иду в топик, выбираю что хочу поучить и развлекаюсь.
Короче бери на заметку, эта штука у меня живет уже как 2-3 года. Первые год использовал в одну харю, а потом расшарил на сотрудников. Прижилось.
Такие дела. Попробуй мож зайдет и ты наведешь порядок в своем хаосе.
🛠 #рабочиебудни
—
✅ @bashdays ✅ @linuxfactory ✅ @blog
У меня оно начиналось как «личное избранное», теперь это стало что-то вроде CRM внутри компании. Каждый сотрудник имеет к такой группе доступ и может закинуть туда что-то своё.
ㅤ
Этакая база данных всяких полезных фич.
Делается это банально. Создаешь приватную группу, включаешь в группе «топики», создаешь нужные топики. Всё!
По необходимости добавляешь в группу людей, либо чисто используешь под свои цели.
На скрине я создал тестовую группу, чтобы показать, как это визуально выглядит (реальную не стал закидывать, чтобы тебя не шокировать письками).
В реалиях у нас эта группа имеет овер 20 топиков, для бухов, для креативщиков, для личных целей и многое другое.
Кто-то посмотрел интересный фильм или увидел шортс который можно сконвертировать во что-то полезное — кидают это в топик.
Например, мемы для @devopsina по сути набираются регулярно в отдельный топик. Каждый день редактор забирает трендовые видосы, обрабатывает их, повышает качество, делает из шакальных - нормальные, генерит в своей голове какие-то айтишные подписи. GPT не используем.
У меня например там есть топик - Гитара, если натыкаюсь на что-то интересное, сохраняю туда. Потом когда появляется желание что-то изучить новое, иду в топик, выбираю что хочу поучить и развлекаюсь.
Короче бери на заметку, эта штука у меня живет уже как 2-3 года. Первые год использовал в одну харю, а потом расшарил на сотрудников. Прижилось.
А еще в телеге есть чеклисты нативные и отдельный топик под это. Опять же когда надо что-то закупить, делаем общий чеклист и потом все это визуально видно, кто что закупил.
Такие дела. Попробуй мож зайдет и ты наведешь порядок в своем хаосе.
—
Please open Telegram to view this post
VIEW IN TELEGRAM
8 57
Сколько линуксоида не корми, он все равно на винду поглядывает.
Накопал я тут тебе WinBoat.
Эта штука запускает Windows-приложения прямо в Linux с максимально «нативной» интеграцией: окна приложений — как обычные X/Wayland-окна, общий доступ к файлам и даже полноценный Windows-десктоп.
Что в коробке
- Запустит любое приложение, которое работает в Windows — в том числе коммерческие программы.
Ради прикола запустил Excel, ну что сказать, минимум приседаний и танцев с бубном. Работает прям отлично.
- Окна приложений интегрируются в рабочий стол Linux, не просто RDP в едином окне, а RemoteApp-композитинг.
ㅤ
- Автоматические инсталляции через GUI — выбираешь параметры, остальное делает WinBoat.
- Файловая интеграция, домашний каталог монтируется в винду.
- Полный Windows-десктоп по запросу (если нужно работать внутри полноценной виртуальной машины).
Что под капотом
Это Electron-приложение + сопутствующий «guest server». Windows запускается как VM внутри контейнера Docker. А между хостом и гостем общаются через WinBoat Guest Server.
Затем для прорисовки отдельных окон используется FreeRDP + Windows RemoteApp — это и даёт ложное ощущение нативности.
Штука интересная возможно бы я ее использовал, если бы плотно сидел на линуксе.
Так что приглядись, глядишь установишь в хозяйстве приживется.
🛠 #утилиты #utilites #linux
—
✅ @bashdays ✅ @linuxfactory ✅ @blog
Накопал я тут тебе WinBoat.
Эта штука запускает Windows-приложения прямо в Linux с максимально «нативной» интеграцией: окна приложений — как обычные X/Wayland-окна, общий доступ к файлам и даже полноценный Windows-десктоп.
Что в коробке
- Запустит любое приложение, которое работает в Windows — в том числе коммерческие программы.
Ради прикола запустил Excel, ну что сказать, минимум приседаний и танцев с бубном. Работает прям отлично.
- Окна приложений интегрируются в рабочий стол Linux, не просто RDP в едином окне, а RemoteApp-композитинг.
ㅤ
- Автоматические инсталляции через GUI — выбираешь параметры, остальное делает WinBoat.
- Файловая интеграция, домашний каталог монтируется в винду.
- Полный Windows-десктоп по запросу (если нужно работать внутри полноценной виртуальной машины).
Что под капотом
Это Electron-приложение + сопутствующий «guest server». Windows запускается как VM внутри контейнера Docker. А между хостом и гостем общаются через WinBoat Guest Server.
Затем для прорисовки отдельных окон используется FreeRDP + Windows RemoteApp — это и даёт ложное ощущение нативности.
Штука интересная возможно бы я ее использовал, если бы плотно сидел на линуксе.
Так что приглядись, глядишь установишь в хозяйстве приживется.
—
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM