Pull to refresh
4
0
Антон Чевычалов @acmnu

Пользователь

Send message
Это не про провайдеров. Удивительно, но там даже админов на билинге может не быть. Т.е. просто нет человека, который поддерживает машину и все. Только менеджеры, которые, когда припечет, пойдут по офису и выдернут кого-нибудь занимающегося сетевыми вопросами, чтоб он попробовал реанимировать машину с Linux и Oracle.
Хорошо, конечно, но что делать с паролями и аккаунтами? Пропускать всех? Или использовать устаревшую базу? А если телефония, то пропускать всех не стоит. Много вопросов тут.
Ещё одна проблема с GOPATH — это форк проектов на github. Решил ты помочь в разработке foo/bar, делаешь форк к себе moi/bar и клонируешь на локальную машину. И все, проект не собирается, поскольку в коде куча мест с import foo/bar/, ну и приходится либо делать симлинк, либо работать с двумя remote в git.
Разумеется не очень, но клиенты нам платят в том числе и за это.
Ну, вот у меня тоже Saas и существенных проблем не было. Вообще, возможно, объемы не те (до 70 000 в день во все стороны). Процент не активных ящиков там велик, но мы стараемся такие вещи отслеживать и чистить базу от мертвяков, хотя это затруднительно с юридической точки зрения. При этом клиенты, которые с головой дружат и используют SPF на своих доменах вообще проблем не испытывают.
Эм. А подскажите мне где вы работаете, я ваши блоки адресов тоже занесу в персональный блок лист. Правильно mail.ru делает. Если вы не хотите бороться со спамом с вашего ip, не подписаны на FBL, то чего вы жалуетесь?

Шаред хостеры с их безобразным отношением к безопасности и непрофессиональными разработчиками сайтов это второй по объему источник спама. Первый (зомби из клиентских сетей) рубится PBL, а вот на вас управы нет ибо можно с водой ребенка выплеснуть.
Да я имелл ввиду, что в принципе никто не включает SPF в стрикт: только что проверил: Гугл, Яндекс, Майлру, все в ~all. SPF у этих ребят уж сколько лет, а все ~. На DMARC конечно есть надежда, поскольку есть репортинг.
Из своих наблюдений я бы сказал, что опытных админов, безопасников и вообще технических спецов, отличает не привычка использования mutt (это редкость), а привычка отключать html отображение писем и нелюбовь к почтовым веб интерфейсам в принципе.
«p=none» просто делает всю эту историю бесполезной. Так же как в SPF все пишут "~all".

Если бы крупные игроки договорились, набрались мужества и поставили p=reject, -all, то это бы дало существенный буст борьбе со спамом. Да, ценой небольших потерь писем, но оно того стоило.
Немного не то. TTL это вещь понятная: наступило событие, если через n секунд не наступило ещё раз, значит дело труба. Во многих системах мониторинга это называется heart beat — отслеживаение периодических событий. В случае бэкапа дело сложнее. Во-первых, расписание не имеет четкого периода. Логика расписания намного сложнее и завязана на бизнес нагрузку (днем легкие инкременталы, ночью полный бэкап, но не в каждую ночь). Во-вторых, нужно анализировать не только время запуска, но и длительность, которая тоже разная в разные периоды месяца, и нужно уметь отследить аномалии в длительности или объеме бэкапа.
Кто-нибудь может подсказать что можно ли подобный софт использовать для мониторинга предопределённых событий? Ну например, каждую ночь идет бэкап определённого хоста. При этом, сутуация, когда он закончился фейлом ловится любой системой мониторинга хорошо, а вот ситуация, когда он вообще в тихую не начался, требует сопоставления с эталонным расписанием. И вот этот случай я как-то не знаю чем можно покрыть. Читаешь о всех этих модных средствах и аж глаза разбегаются.
Ну как бы на данный момент, как я уже говорил, уже есть релиз, который уже работает, в котором есть подсветка синтаксиса, все базовые кнопки, макросы, визуальный мод, множественные курсоры (новшество, относительно вим).

Им уже можно пользоваться как редактором. Что я и делаю последние два дня.
Ну я не могу говорить за авторов, но лично я бы не отказался от vim подобного редактора с хорошим RPC, чтоб писать плагины на том языке, который удобен в данном, конкретном случае.

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

Т.е. грубо говоря цель это проекта редактор и ничего более.
Кому любопытно, появился проект написания с нуля редактора цель которого выполнять 80% команд vim, при размере кодовой базы в 1%.

Полная совместимость не планируется, но цель сделать нечто очень похоже. Vim Script, продвинутое управление окнами, GUI реализовываться не будут принципиально. Нормальная подстветка синтаксиса уже сделана. В качестве внутреннего языка используется Lua. Запланирован RPC для внешнего управления (это вместо плагинов).

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

Проект находится вот здесь: github.com/martanne/vis

Пока у тебя нет монопольного положения на рынке, безусловно можешь, поскольку недовольный твоими действиями клиент уйдет к другому. Как только ты стал монополистом, дело меняется. Монополия опасная вещь: американцы с ней настрадались сильно, поэтому антимонопольное законодательство в целом несправедливо по отношению к монополисту, но зато эффективно избавляет рынок от куда более сложных проблем.
Ааа. Т.е. в минус можно уйти. Да, ерунда какая-то.
При использовании UDP в качестве транспорта для событий есть одна мелочь, на которую я нарывался. Протокол syslog предполагает необязательность поля TIMESTAMP. В этом случае метку времени обычно проставляет принимающая сторона, но UDP может задержаться в пути и так как никакого контроля очередности (как в TCP) нет, то пакеты обработаются в другом порядке, что может сильно осложнить исследование логов. Поэтому приложение должно проставлять таймстамп при генерации события, а принимающая сторона не должна эти стампы игнорить (а есть соблазн так сделать, чтоб синхронизировать логи от разных источников). Оригинальный код libc проставляет время, но сторонние реализации могут на это забить, а зря.
Вообще со временем в syslog засада. Поле таймстамп это просто текст. В этот текст должно вставляться смещение относительно GMT. Но на деле эта информация бывай кем-нибудь да дропится (особенно в собственных костылях), и в результирующий текстовый лог попадает локальное время клиента не пересчитаное во время принимающей стороны. Если у вас куча серверов работает в разных таймозонах тут вам придется походить по граблям. Ну или перевести все сервера в GMT (не всегда возможно, к сожалению).
Многие банки такую услугу предоставляют: карта, которой можно пользоваться только для онлайн платежей. Стоит обычно около 1 доллара в месяц, а то и бесплатно, если вы привилегированный клиент. Закидываете на эту карту ровно 20 долларов, в минус на ней нельзя уйти (впрочем читайте мануал вашего банка, мало ли что). Ну а пополнение онлайн с другой карты или счета в том же аккаунте это дело нескольких минут.
Я к тому, что ваша проблема с каскадным отказом возможно решалась не написанием "собственного syslog по UDP", а просто переключением связи между главным демоном цода и демоном машины в UDP режим. Да, вы бы теряли логи, но не теряли стабильность. Честно говоря я ни разу не видел случая, что кто-нибудь включал TCP на передачу syslog в сети.
Я правильно понял, что между локальными для физической машины rsyslog демоном и центральным демоном ЦОДа у вас был TCP? Ведь протокол syslog изначально подразумевает UDP.

Information

Rating
5,672-nd
Registered
Activity

Specialization

DevOps, Chief information officer (CIO)
Lead