Мне кажется те, кто «с консолью на вы», не должны решать срочных задач в консоли, потому что в 99% случаев (appx/bome) это заканчивается поисками тех кто с консолью работает каждый день чтобы починить не работающий сервис.
Makefiles! Makefiles! Скорее бы уже. Я каждый день использую либо Go[g]Land, либо PyCharm, либо NetBeans, ибо CLion все-еще не поддерживает GNU make, и как-то становится обидно что плачу за весь toolbox, а пользуюсь только на 2/3.
Хоть какой-нибудь примерный ETA можете подсказать, когда нам уже придет счастье?
программисты на Objective-C на пенсию уйдут, а кто будет этот их код в ядре и ключевых компонентах системы поддерживать
SDK/фреймфорки != ядро/OS. Драйвера для устройств и все компоненты системы низкого уровня там написаны на C/C++, графическая оболочка и прочие надстройки это отнюдь не «ключевые компоненты системы».
Что-то я очень сильно сомневаюсь что код в ядре пишут на Objective-C, там даже C++ не особо-то видно, все пишется на старом добром C который никуда не денется. Все что в ядре написано на Objective-C или Swift это в основном интерфейсы чтобы вы могли SDK на этих языках использовать.
Передаю с места событий. Запрет не сняли, криптовалюты не запретили, а запретили обмен RMB (китайского юаня) на криптовалюты (ну и «добровольно» закрыли обменники где можно было менять RMB — крипто)
И с тех пор никаких новостей о том разрешат ли опять или какие-либо правила введут. Так что Китай, никак не попадает в ту же группу что США, так как США вообще пока никак не регулируют.
Я как бы думал что SMTP не имеет ничего общего с HTTP за исключением того что они оба используют TCP. Т.е. TCP надо заменить чем-то?
То что оба протокола начали как текстовые обосновано тем, что в то время когда они создавались было невозможно (ну или крайне сложно) дебажить сетевые приложения. Поэтому «дебажились» они вручную. Вот только Ваш комментарий что оба протокола текстовые морально устарел еще до того как вы его написали. HTTP/2 и SPDY полностью бинарные протоколы, SMTP без TLS сейчас очень мало где используется, что опять в своем роде делает его бинарным (а как вы хотите переправлять текст в не-текстовом формате? email это же для людей читать, так что он натурально текстовый).
Хорошая статья, годная, мне ничего нового, но думаю многим пригодится. Еще можно по той же теме затронуть такие sysctl параметры как tcp_timestamps, tcp_syn* и nf_conntrack_* (которые могут спасти от SYN-flood'а и просто пикового траффика без CDN и SMS), tcp_tw_*, tcp_*_timeout, tcp_keepalive_* (которые могут безболезненно увеличить пропускную способность машины), и т.д. Очень обширная тема.
Вообще, многие думаю не знают что дефолтные настройки ядра далеко не самые оптимальные для серверов. Но, конечно, перед тем как что-то крутить нужно понимать что это и как оно работает, для чего есть очень хорошие комментарии прямо в коде ядра где можно посмотреть текст и убедиться что имплементация работает именно так.
Я вот как раз такими же вопросами задался некоторое время назад и из этого родилось вот такое чудовище, там точно так же как и в экспрессе можно сделать чтобы несколько handlers отработали в определенном порядке.
Кстати, один я заметил интересную особенность, что на Go активно переходят только PHP-шнки т.е. в большинстве своем те люди, которые привыкли писать лапшеобразный код.
Перешел на Go с С/С++, Java и Python (для новых проектов). Очень счастлив что это сделал, теперь трачу больше времени на написание кода приложений, чем на отладку и попытки понять почему у меня огнестрельная рана в ноге. Веб приложения не пишу, лапшу не пишу (по-крайней мере стараюсь не писать). Я что-то делаю не так?
Итогом является закономерный Го-внокод.
Мне кажется Вы приписываете языку то, что относится к самим программистам. Если программист пишет говнокод на PHP и JS, то переход на тот-же D это не исправит.
Так как всем управляет Jenkins, то у нас делается в два этапа:
— первая задача собирает пакет по триггеру из репозитория и кладет пакет в промежуточную директорию, в конце она вызывает задачу номер 2
— вторая задача смотрит что лежит во временной директории, подписывает, кладет в WebRoot, обновляет мета-данные и подписывает их
При этом у второй задачи в настройках указано — ждать если есть другие задачи в очереди, т.е. если у меня одновременно два (или больше) пакета собирается, то вторая задача не начнет выполнятся пока не появится окно между сборками. Чтобы особо долго не ждать можно выставить в настройках чтобы вторая задача ждала не дольше определенного времени. Т.е. я сначала аггрегирую пакеты которые уже готовы и вторая задача их все вместе зальет.
Еще в Jenkins можно отключить параллельное исполнение одной и той же задачи, т.е. даже если есть свободные воркеры, повторный вызов просто встанет в очередь.
У нас примерно тоже самое только через Jenkins:
Jenkins собирает пакет после merge в репозитории
Он же подписывает этот пакет (да-да в статье не написано, но это считается дурным тоном не подписывать rpm пакеты)
Он же заливает пакеты в репозиторий (через sshfs)
Он же обновляет мета-данные репозитория и подписывает их
И все настраивается красиво через WebUI. Непонятно зачем такие сложности с написанием своего велосипеда на Python
Это я о том что Git изначально заточен под работу именно в стиле kernel. Те кто пользуется Github используют в лучшем случае 20% от всей функциональности Git'а, а остальные функции для этих пользователей выглядят сложными и часто ненужными (достаточно погуглить на англ про git-rebase, например, очень много кто не понимает разницу, или тот же cherry-pick, хотя обе функции активно используются в kernel и других масштабных проектах).
Я думаю не все в курсе, а статья не упоминает, что сам Git был разработан Линусом, как раз таки специально для того чтобы хостить код ядра. Github же предоставляет достаточно урезанную по функциональности версию Git.
Если нет проблем с англ. очень советую прочитать вот эту статью про достоинства и недостатки FreeIPA+SSSD+MFA, но эта статья достаточно старая и многие указанные там недостатки уже были исправлены (в статье есть ссылки на соответствующие дискусси разработчиков)
Спасибо за статью! Было бы очень интересно прочитать про то как добавить умные контракты в логику блокчейна. Я тут в свободное время занимаюсь написанием игрушечного/учебного блокчейна, но пока не разобрался как добавить туда engine для этих умных контрактов.
Ну у нас как бы тоже самое. Сервера не свои, а клиентские. Своих и клиентских пользователей мы добавляем в LDAP. Наши пользователи имеют доступ ко всем серверам, но только по определенному тикету, если нет тикета, нет и доступа. Клиентские пользователи имеют доступ только к своим серверам, но у них доступ не ограничен тикетом (может быть ограниченный sudo, например разработчики могут переключится на пользователя под которым работает приложение, или только могут управлять определенными процессами).
Пароли, ключи, MFA, время доступа, какие команды могут быть выполнены с sudo, на какие сервера можно залогиниться и откуда. Все это вполне себе управляется через LDAP.
Как я сказал выше этот продукт не добавляет ничего нового, а только является очень очень странным велосипедом в области где все уже вполне себе хорошо не первый год.
How could we prevent a system from being compromised when someone lost the laptop with ssh key. What would we do in case someone quits the company — is there an alternative to just changing all passwords, keys, etc?
Судя по вот этому ваше решение это велосипед который игнорирует уже существующие системы (которые к слову развивались не один год). Простейший OpenLDAP+SSSD позволит в одну минуту заблокировать пользователя на всех серверах + отозвать sudo привилегии + отозвать доступ к сервисам которые работают через PAM или напрямую через LDAP и т.д. и т.п. И все это сделано централизованно без необходимости использовать несуразный Ansible (его сейчас вообще очень модно использовать где попало). Опять же с банальным OpenLDAP и SSSD можно включить MFA на всех устройствах. А если идти более сложным путем (FreeIPA) то открывается еще больше возможностей.
Дисклеймер: Я не против Ansible, и сам его использую чтобы поддерживать примерно 1.5к серверов. Но я точно не хочу использовать его для вот таких вещей.
Хоть какой-нибудь примерный ETA можете подсказать, когда нам уже придет счастье?
SDK/фреймфорки != ядро/OS. Драйвера для устройств и все компоненты системы низкого уровня там написаны на C/C++, графическая оболочка и прочие надстройки это отнюдь не «ключевые компоненты системы».
Так же они в сентябре запретили обмен юаня на крипто-коины.
И с тех пор никаких новостей о том разрешат ли опять или какие-либо правила введут. Так что Китай, никак не попадает в ту же группу что США, так как США вообще пока никак не регулируют.
Я как бы думал что SMTP не имеет ничего общего с HTTP за исключением того что они оба используют TCP. Т.е. TCP надо заменить чем-то?
То что оба протокола начали как текстовые обосновано тем, что в то время когда они создавались было невозможно (ну или крайне сложно) дебажить сетевые приложения. Поэтому «дебажились» они вручную. Вот только Ваш комментарий что оба протокола текстовые морально устарел еще до того как вы его написали. HTTP/2 и SPDY полностью бинарные протоколы, SMTP без TLS сейчас очень мало где используется, что опять в своем роде делает его бинарным (а как вы хотите переправлять текст в не-текстовом формате? email это же для людей читать, так что он натурально текстовый).
Фабрика = Factory; Fabric = Ткань
<зануда mode off>
Там вообще весь текст как копипаста из онлайн переводчика:
И так далее
Вообще, многие думаю не знают что дефолтные настройки ядра далеко не самые оптимальные для серверов. Но, конечно, перед тем как что-то крутить нужно понимать что это и как оно работает, для чего есть очень хорошие комментарии прямо в коде ядра где можно посмотреть текст и убедиться что имплементация работает именно так.
Перешел на Go с С/С++, Java и Python (для новых проектов). Очень счастлив что это сделал, теперь трачу больше времени на написание кода приложений, чем на отладку и попытки понять почему у меня огнестрельная рана в ноге. Веб приложения не пишу, лапшу не пишу (по-крайней мере стараюсь не писать). Я что-то делаю не так?
Мне кажется Вы приписываете языку то, что относится к самим программистам. Если программист пишет говнокод на PHP и JS, то переход на тот-же D это не исправит.
— первая задача собирает пакет по триггеру из репозитория и кладет пакет в промежуточную директорию, в конце она вызывает задачу номер 2
— вторая задача смотрит что лежит во временной директории, подписывает, кладет в WebRoot, обновляет мета-данные и подписывает их
При этом у второй задачи в настройках указано — ждать если есть другие задачи в очереди, т.е. если у меня одновременно два (или больше) пакета собирается, то вторая задача не начнет выполнятся пока не появится окно между сборками. Чтобы особо долго не ждать можно выставить в настройках чтобы вторая задача ждала не дольше определенного времени. Т.е. я сначала аггрегирую пакеты которые уже готовы и вторая задача их все вместе зальет.
Еще в Jenkins можно отключить параллельное исполнение одной и той же задачи, т.е. даже если есть свободные воркеры, повторный вызов просто встанет в очередь.
Jenkins собирает пакет после merge в репозитории
Он же подписывает этот пакет (да-да в статье не написано, но это считается дурным тоном не подписывать rpm пакеты)
Он же заливает пакеты в репозиторий (через sshfs)
Он же обновляет мета-данные репозитория и подписывает их
И все настраивается красиво через WebUI. Непонятно зачем такие сложности с написанием своего велосипеда на Python
Пароли, ключи, MFA, время доступа, какие команды могут быть выполнены с sudo, на какие сервера можно залогиниться и откуда. Все это вполне себе управляется через LDAP.
Как я сказал выше этот продукт не добавляет ничего нового, а только является очень очень странным велосипедом в области где все уже вполне себе хорошо не первый год.
Судя по вот этому ваше решение это велосипед который игнорирует уже существующие системы (которые к слову развивались не один год). Простейший OpenLDAP+SSSD позволит в одну минуту заблокировать пользователя на всех серверах + отозвать sudo привилегии + отозвать доступ к сервисам которые работают через PAM или напрямую через LDAP и т.д. и т.п. И все это сделано централизованно без необходимости использовать несуразный Ansible (его сейчас вообще очень модно использовать где попало). Опять же с банальным OpenLDAP и SSSD можно включить MFA на всех устройствах. А если идти более сложным путем (FreeIPA) то открывается еще больше возможностей.
Дисклеймер: Я не против Ansible, и сам его использую чтобы поддерживать примерно 1.5к серверов. Но я точно не хочу использовать его для вот таких вещей.