А можно по подробнее (желательно в виде документации к API)?
Сам бризер умеет только BT LE. Как я сейчас понимаю речь про вариант с базовой станцией, которая и обеспечивает этот API. С самой станцией дела не имел, поскольку решил что она замкнута на себя и свои/интегрированные датчики/устройства (типа тех е Danfoss), а потрогать ее руками возможность не было.
Deuter 20 литров. Ширина спины подобрана в соответствии с размером ноута.
Мой опыт выбора рюкзака говорит о том что в любой хороший рюкзак можно положить все необходимое (при соответствии габаритов). Для меня «хороший» рюкзак это:
проверенного производителя рюкзаков. Если Компания не знает как сделать рюкзак который можно носить 4 недели в походе, то удобный и надежный рюкзак у нее сделать не получится. Так что выбор для меня сразу ограничивается на Deuter, Bask и Tatonka + конторы классом выше, на которые можно смотреть не сильно конфликтуя с Жабой;
удобно сидящий. Проверяется только личной примеркой: в рюкзак кладется все что там должно быть абы как и еще пихается пара вещей из магазина, для увеличения объема. Все должно влезть и удобно сидеть на спине. Даже ноут лежащий под углом к спине не должен мешаться. Сюда же и широкие лямки: стропы 2см шириной, как на многих фото, — это совсем не то, что будет обеспечивать комфорт плечам спустя пару часов хождения с рюкзаком;
удобно организованный. То что должно быть под рукой — должно быть под рукой и не выпадать. Клапан, карманы на молнии итд;
имеющий утяжки. Я иногда вместо 20л беру утянутый рюкзак с вентилируемой спиной на 35л, который просто выглядит гораздо меньше и аккуратнее;
без поясного и грудного ремней. Это, обычно, для города лишнее. Их нехватка, для меня, проявляется примерно через 3 часа перемещений с рюкзаком 10+ кг. Там хочется и плечи разгрузить и лямки сдвинуть.
В комплекте с первым пунктом обычно идет надежность и защищенность: текущему рюкзаку уже лет 6 и он под дождем до сих пор не промокает (хотя уже на дне протерся до дыр).
С «уронить» чуть сложнее. Со стороны плоскостей рюкзак защищает содержимое сам по себе достаточно хорошо. Единственное что требуется — защита в нижней части. Если бы мне потребовалось, то решал бы не специальным рюкзаком для ноута", а подкладыванием блока какого-нибудь упаковочного материала на дно: тут и толщина будет достаточная и веса лишнего не даст.
В модифицированном нами коде bash оказался другой баг, из-за которого интерпретатор при обнаружении пустой строки в конце конфигурационного файла входил в бесконечный цикл и переставал отвечать на внешние команды.
А зачем вообще трогать системный bash? #!/usr/local/super_bash/bin/bash прекрасно справляется с задачей установки подходящего интерпритатора для скрипта.
Да и невозможность штатного обновления выглядит странно. Для меня это звучит примерно так: «скрипты были написаны абы как, без соблюдения требований и стандартов».
И, кстати, очень хотелось бы взглянуть на пример кода, который заставлял отказываться от обновленных версий в пользу ручной модификации кода интерпритатора (для самообразования, что бы так не делать)
У гелия в дисках есть еще одно существенное отличие от воздуха: вязкость.
Если в дисках с воздухом пластины расположить очень близко друг к другу, то какие бы они ни были гладкие, между пластинами будут возникать турбулентные потоки, которые буду влиять на головку. У гелия же вязкость меньше и пластины можно расположить ближе друг к другу, без возникновения существенных турбулентных потоков, что позволяет увеличить емкость диска, при сохранении его типоразмера.
Еще следует не забывать, что коптеры «под GoPro» идут без камеры в комплекте. Так что + еще и цена камеры. И сигнал с этой самой GoPro нужно как-то доставить на землю (или забыть про FPV полеты).
Я свои копетры посчитал: у меня получилось что камера + оборудование для передачи сигнала — почти половина итоговой стоимости коптера.
Чтож, полагаю что в ошибочности первого пункта вашего review на мой код сомневаться больше не приходится. Я бы с удовольствием прошелся по остальным, но это выходит за рамки зявленной автором топика темы.
Теперь вернемся к оригинальной теме этого топика — виртуальным ресурсам в puppet.
Мой пример иллюстрирует лишь то, что использование виртуальных ресурсов избыточно (Ваша просьба примера использования одинаковых пользоватеелй в разных классах/сервисах, впрочем, тоже, поскольку вирутальные ресурсы решают имено проблему вызова одинаковых ресурсов из разных классов). Иллюстрирует он это в тех же терминах, что и автор этого поста: применительно к ресурсу user.
Но и Вашу просьбу о примере без ответа я оставить не могу (хотя он тут же будет назван «специфическим», но мы же сейчас не решаем какую-то реальную задачу, а обсуждаем общие принципы, связанные с виртуальными ресурсами).
Итак, пример.
Распределенное дисковое хранилище, dCache, для организации доступа по протоколу srm, требует установленные на зулах x509 сертификаты, которые должны принадлежать тому же пользователю, от которого dCache запусакется. Сертификаты обновляются каждый год. Тому же пользователю должны принадлежать все конфигурационыне файлы. Итого: классу, настраивающему dCache требуется тот же пользователь, что и классу, который кладет сертификаты на сервер.
Конечно. Puppet, при передаче в define (или любой тип, вроде user) массива в виде title, разворачивает его на отдельные элементы и делает вызов для каждого элемента. По этому имеем:
define create_users ($users=$title) {
$users.each |$user| {
include "users::$user"
}
}
class users {
User { ensure => present }
}
class users::user1 inherits users {
user{'user1':}
}
class users::user2 inherits users {
user{'user2':} ->
file{'/mnt/user2':
ensure => 'directory',
owner => 'user2',
}
}
class apache {
create_users{[ 'user1', 'user2' ]: }
}
class other_service {
create_users{[ 'user1' ]: }
}
include apache
include other_service
И в результате:
puppet apply test.pp
Error: Evaluation Error: Error while evaluating a Resource Statement, Duplicate declaration: Create_users[user1] is already declared in file /root/test.pp:23; cannot redeclare at /root/test.pp:26 at /root/test.pp:26:3 on node mynode
Error: Evaluation Error: Error while evaluating a Resource Statement, Duplicate declaration: Create_users[user1] is already declared in file /root/test.pp:23; cannot redeclare at /root/test.pp:26 at /root/test.pp:26:3 on node mynode
Более того, если мы захотим передать хэш в виде title у нас тоже ничего не получится (но, правда по другим причинам). По этому с массивами нужно быть крайне аккуратным и each внутри define вполне имеет право на жизнь.
Про кто-то не прав — спасибо, что обратили внимание. Я тоже немного переборщил.
А по существу
1) define успешно принимает массив, each не нужен
Тут возникнет проблема если два класса решат создать одинаковых пользователей.
Именно по этому у меня в title поставлено $name, а массив передается через параметр.
5) Такое ощущение, что классы писал кто-то, впервые увидевший puppet и использующий одинаковые имена пользователей в разных классах (точнее в том, что при правильном дизайне должно быть разными модулями).
За «впервые увидевший puppet» отдельное спасибо.
А по существу: вполне бывает так что разным сервисам (в том что 1 модуль у нас настраивает один сервис разночтений же нет? Комбайны делающие все никто не пишет?) требуются одинаковые пользователи (раз уж все с пользователей началось). Значит вполне логично что каждый настраиваемый список имеет список необходимых ему пользователей, в котором пользователи могут пересекаться.
Да, а теперь вопрос: зачем тут виртуальные ресурсы? Почему бы пользователей не создавать в классах с действиями, например вот так:
define create_users ($users) {
$users.each |$user| {
include "users::$user"
}
}
class users {
User { ensure => present }
}
class users::user1 inherits users {
user{'user1':}
}
class users::user2 inherits users {
user{'user2':} ->
file{'/mnt/user2':
ensure => 'directory',
owner => 'user2',
}
}
class apache {
create_users{"$name":
users => [ 'user1', 'user2' ],
}
}
class other_service {
create_users{"$name":
users => [ 'user1' ],
}
}
node 'testnode.example.com' {
include apache
include other_service
}
И это же ответ на ваш первый вопрос про действия при создании пользователей. И, за одно, про сравнение кода с include и виртуальными ресурсами.
Да и неправильно использовать его нельзя: при создании пользователя выполняется все, что должно выполнится при создании пользователя.
Допустим, нужно создать пользователя и положить ему bashrc, ssh ключи или сделать владельцем каталогов. В общем любая операция, связанная с пользователем, которая должна быть выполнена и без которой пользователя создавать не следует.
А мой пример с «1 пользователь = 1 класс» начинает прекрасно работать в тот момент, когда кроме создания пользователя нужно делать что-то еще, специфичное для пользователя. С виртуальными ресурсами, на сколько я понимаю, такой фокус не сработает.
Я в вашем примере одного не понял: зачем вводить виртуальные ресурсы?
if ( ! defined(User['webUser']) ) { user { 'webUser': ensure => present } }
Главная идея в том, что пользователи во всех классах должны создаваться (и определяться) одинаково. И именно это главное преимущество виртуальных ресурсов, перед конструкцией приведенной выше. В случае виртуальных ресурсов он определяется один раз и вызывается из неограниченного числа мест.
Но можно обойтись и без виртуальных ресурсов: один пользователь = 1 класс (ну или подкласс в users). И делать include каждого такого класса-пользователя. Эффект будет точно таким же.
А скорость работы сайта состоящего из index.html не тестировалась?
Да, по мере роста количества материалов на сайте ситуация может существенно измениться, но резульат такого теста будет говорить о многом.
В CMS важно не то как быстро она делает SELECT count(*) FROM posts и убеждается что постов ноль, а то как она себя ведет под реальной нагрузкой.
Мне бы, например, было бы нтересно посмотреть на эволюцию времени отклика в зависимости от количества записей при обращении к случайным страницам. Увидеть «полочки», понять почему они происходят и как на «полочке» продержаться подольше.
Еще в вашем случае уместно такое решение для динамических IP:
Создаете отдельную цепочку для динамических IP и 22 локального порта на сервере доступа
По крону, раз в 5 минут, например, цепочку очищаете и добавляете актуальные IP
Что бы получать актуальные IP можно воспользоваться сервисами типа DynDNS.
Это, конечно, скрывает потенциальную дыру в безопасности (через атаки на DNS), но это все же лучше чем пускать всех подряд.
Первым шагом мы через систему управления конфигурациями распространили на все физические сервера ssh ключи, для входа на них с серверов доступа без пароля
А чем не устроили парольные ключи и ssh-agent?
В идеале, для доступа на клиентские серверы не должен использоваться ключ с центрального узла. Только персонифицированные ключи администраторов, защищенные паролями.
Те все должно происходить так:
Админ экспортирует свой ключ для целевого сервера в ssh-agent и заходит на управляющий сервер («сервер доступа»)
Используя свой персональный ключ (пробрасываемый агентом) заходит на целевой сервер
Это позволяет решить проблему со взломом центарльного сервера: на нем нет никаких ключей, тем более беспарольных, а значит доступ к нему можно по ssh открыть, не боясь что при его взломе получат доступ к внутрененй инфраструктуре. + такой подход позволяет разграничивать доступ для админов: они могут иметь один аккаунт на центральном сервере, но при этом иметь доступ только на те узлы, на которые должны попадать (не говоря уже о том что можно хоть на каждый сервер уникальный ключ иметь и не как не влиять при этом на остальных администраторов)
Соглашусь.
Но мне ближе linux-way, если позволите такую формулировку: одна утилита делает одну операцию, но делает ее хорошо.
Но если мне предложат иллюзию выбора в виде двух альтернатив: ФТС у черта на рогах и почта, я подумаю, но выберу почту.
Хотя мне был бы более удобен сайт, который умеет принимать различные способы оплаты и проставляет статус посылки «оплачено», который виден на почте. Оплатил с карты дома в два часа ночи, на следующий день, как обычно, пришел и получил.
Сам бризер умеет только BT LE. Как я сейчас понимаю речь про вариант с базовой станцией, которая и обеспечивает этот API. С самой станцией дела не имел, поскольку решил что она замкнута на себя и свои/интегрированные датчики/устройства (типа тех е Danfoss), а потрогать ее руками возможность не было.
Мой опыт выбора рюкзака говорит о том что в любой хороший рюкзак можно положить все необходимое (при соответствии габаритов). Для меня «хороший» рюкзак это:
В комплекте с первым пунктом обычно идет надежность и защищенность: текущему рюкзаку уже лет 6 и он под дождем до сих пор не промокает (хотя уже на дне протерся до дыр).
С «уронить» чуть сложнее. Со стороны плоскостей рюкзак защищает содержимое сам по себе достаточно хорошо. Единственное что требуется — защита в нижней части. Если бы мне потребовалось, то решал бы не специальным рюкзаком для ноута", а подкладыванием блока какого-нибудь упаковочного материала на дно: тут и толщина будет достаточная и веса лишнего не даст.
У меня лампы с таким димером включаются в начале на минимальной яркости, а потом разгораются до заданной.
Да и невозможность штатного обновления выглядит странно. Для меня это звучит примерно так: «скрипты были написаны абы как, без соблюдения требований и стандартов».
И, кстати, очень хотелось бы взглянуть на пример кода, который заставлял отказываться от обновленных версий в пользу ручной модификации кода интерпритатора (для самообразования, что бы так не делать)
Если в дисках с воздухом пластины расположить очень близко друг к другу, то какие бы они ни были гладкие, между пластинами будут возникать турбулентные потоки, которые буду влиять на головку. У гелия же вязкость меньше и пластины можно расположить ближе друг к другу, без возникновения существенных турбулентных потоков, что позволяет увеличить емкость диска, при сохранении его типоразмера.
Я свои копетры посчитал: у меня получилось что камера + оборудование для передачи сигнала — почти половина итоговой стоимости коптера.
Теперь вернемся к оригинальной теме этого топика — виртуальным ресурсам в puppet.
Мой пример иллюстрирует лишь то, что использование виртуальных ресурсов избыточно (Ваша просьба примера использования одинаковых пользоватеелй в разных классах/сервисах, впрочем, тоже, поскольку вирутальные ресурсы решают имено проблему вызова одинаковых ресурсов из разных классов). Иллюстрирует он это в тех же терминах, что и автор этого поста: применительно к ресурсу user.
Но и Вашу просьбу о примере без ответа я оставить не могу (хотя он тут же будет назван «специфическим», но мы же сейчас не решаем какую-то реальную задачу, а обсуждаем общие принципы, связанные с виртуальными ресурсами).
Итак, пример.
Распределенное дисковое хранилище, dCache, для организации доступа по протоколу srm, требует установленные на зулах x509 сертификаты, которые должны принадлежать тому же пользователю, от которого dCache запусакется. Сертификаты обновляются каждый год. Тому же пользователю должны принадлежать все конфигурационыне файлы.
Итого: классу, настраивающему dCache требуется тот же пользователь, что и классу, который кладет сертификаты на сервер.
И в результате:
Более того, если мы захотим передать хэш в виде title у нас тоже ничего не получится (но, правда по другим причинам). По этому с массивами нужно быть крайне аккуратным и each внутри define вполне имеет право на жизнь.
А по существу
Тут возникнет проблема если два класса решат создать одинаковых пользователей.
Именно по этому у меня в title поставлено $name, а массив передается через параметр.
За «впервые увидевший puppet» отдельное спасибо.
А по существу: вполне бывает так что разным сервисам (в том что 1 модуль у нас настраивает один сервис разночтений же нет? Комбайны делающие все никто не пишет?) требуются одинаковые пользователи (раз уж все с пользователей началось). Значит вполне логично что каждый настраиваемый список имеет список необходимых ему пользователей, в котором пользователи могут пересекаться.
А оригинально дискуссия была о том, что виртуальные ресурсы не дают дополнительной пользы: все что они делают можно сделать и без них.
И это же ответ на ваш первый вопрос про действия при создании пользователей. И, за одно, про сравнение кода с include и виртуальными ресурсами.
Да и неправильно использовать его нельзя: при создании пользователя выполняется все, что должно выполнится при создании пользователя.
А мой пример с «1 пользователь = 1 класс» начинает прекрасно работать в тот момент, когда кроме создания пользователя нужно делать что-то еще, специфичное для пользователя. С виртуальными ресурсами, на сколько я понимаю, такой фокус не сработает.
Главная идея в том, что пользователи во всех классах должны создаваться (и определяться) одинаково. И именно это главное преимущество виртуальных ресурсов, перед конструкцией приведенной выше. В случае виртуальных ресурсов он определяется один раз и вызывается из неограниченного числа мест.
Но можно обойтись и без виртуальных ресурсов: один пользователь = 1 класс (ну или подкласс в users). И делать include каждого такого класса-пользователя. Эффект будет точно таким же.
Да, по мере роста количества материалов на сайте ситуация может существенно измениться, но резульат такого теста будет говорить о многом.
В CMS важно не то как быстро она делает SELECT count(*) FROM posts и убеждается что постов ноль, а то как она себя ведет под реальной нагрузкой.
Мне бы, например, было бы нтересно посмотреть на эволюцию времени отклика в зависимости от количества записей при обращении к случайным страницам. Увидеть «полочки», понять почему они происходят и как на «полочке» продержаться подольше.
Что бы получать актуальные IP можно воспользоваться сервисами типа DynDNS.
Это, конечно, скрывает потенциальную дыру в безопасности (через атаки на DNS), но это все же лучше чем пускать всех подряд.
А чем не устроили парольные ключи и ssh-agent?
В идеале, для доступа на клиентские серверы не должен использоваться ключ с центрального узла. Только персонифицированные ключи администраторов, защищенные паролями.
Те все должно происходить так:
Это позволяет решить проблему со взломом центарльного сервера: на нем нет никаких ключей, тем более беспарольных, а значит доступ к нему можно по ssh открыть, не боясь что при его взломе получат доступ к внутрененй инфраструктуре. + такой подход позволяет разграничивать доступ для админов: они могут иметь один аккаунт на центральном сервере, но при этом иметь доступ только на те узлы, на которые должны попадать (не говоря уже о том что можно хоть на каждый сервер уникальный ключ иметь и не как не влиять при этом на остальных администраторов)
Но мне ближе linux-way, если позволите такую формулировку: одна утилита делает одну операцию, но делает ее хорошо.
Но если мне предложат иллюзию выбора в виде двух альтернатив: ФТС у черта на рогах и почта, я подумаю, но выберу почту.
Хотя мне был бы более удобен сайт, который умеет принимать различные способы оплаты и проставляет статус посылки «оплачено», который виден на почте. Оплатил с карты дома в два часа ночи, на следующий день, как обычно, пришел и получил.