Закрытый ключ прекрасно экспортируется. Это факт. Экспортировал в 2016 году. Специализированного софта для этого не устанавливал — только КриптоПро 3.9 КС1
Про CSP вы совершенно правы. Про КП JCP — не уверен. Я Java не использую, но КП.NET совершенно точно лицензируется по используемой операционной системе и не важно, что использование КП.NET ограничивается клиентскими нуждами. Благо, для КП.NET лицензирование не по ядрам :).
Вы что-то делаете не так. Приведенная ссылка на форум — 6 летней давности. Сейчас ключи прекрасно экспортируются в PFX и импортируются обратно. Я сам очень давно (лет 5-6 назад) сталкивался с проблемой невозможности экспорта в PFX, однако, относительно недавно обнаружил, что это работает — изучая пример, идущий с КриптоПро.NET SDK (как раз про SMEV), обнаружил там в каталоге Certificates примеры ключей в PFX и в readme.txt написано что эти PFX устанавливаются штатными средствами системы. Проверил на своих сертификатах — действительно, всё работает.
> Ведомствам издателям сертификатов теперь ЗАПРЕЩЕНО вносить с сертификаты дополнительные поля и требования их обязательности
Хотел уже было поругаться с Росреестром, который не принимает мою ЭЦП из за отсутствия в ней соответствующего OID-а, однако, более детальное изучение закона подсказало, что этот запрет вступает в силу только 08.07.2016…
Если хочется без нервотрепки, то должен быть на готове сервер с необходимыми ресурсами (место на диске, память, процессоры). Если есть такой сервер, то достаточно включить log shipping и не нужно будет никакие километры логов восстанавливать, да и время на восстановление уйдёт гораздо меньше.
Нам в банках, действительно, нужен КБК для заполнения платежек. Однако, есть пара нюансов, которые открытость данного перечня, на мой взгляд, ситуацию не изменит:
1. если платежку приности юридическое лицо (на бумаге или в банк-клиент), то какой там КБК написан, с таким и отправим — у нас нет опции изменять реквизиты, у нас нет оснований отказывать в приеме платежки. Банки не в состоянии брать на себя миссию убеждения бухгалтеров, которые составляют платежки, в том, что они неправильно это делают.
2. п.1 в той же мере относится и к физическим лицам, однако, как правило, они не имеют банковского счета и приходят не с готовой платежкой, а с реквизитами (на клочке бумаги, на квитанции по форме ПД-4 и т.п.). Большая часть клиентов приходят с квитанцией по форме ПД-4. Эти квитанции в большинстве своём заполнены получателем платежа (администратором дохода). Здесь наши руки тоже связаны — клиент понятия не имеет что на этой квитанции написано (кроме суммы и общего представления за что именно он платит), а миссия убеждения банками бухгалтеров администраторов доходов ещё менее реализуема, чем в п.1
В любом случае, наличие открытого перечня КБК будет лучше, чем его отсутствие, так что спасибо Вам за Ваше начинание.
2-6 серверов Hi-End класса, по 180 миллионов рублей каждый, плюс 4-10 блейд-серверов (заполненных шасси) по 800 тысяч рублей
Какие-то очень странные цифры… что за сервера такие за 180 млн рублей каждый?
Касательно заполненных блейд-шасси — тоже интересно где такие цены? (даже учитывая вторую звёздочку — по состоянию на полгода назад)… в моём понимании за 800 тыс. с натяжкой (без резервирования сети и FC) можно купить пустое шасси. А туда нужно ещё лезвия докупать (10-16-32 штук, по стоимости от 250 тыс. до 1 млн. каждое).
Всё равно не понимаю смысл проверки наличия записи.
либо транзакция, добавившая потребителя, еще не была завершена
Вы не сможете эту запись обновить пока транзакция, добавившая потребителя не завершится. Профит от проверки в транзакции, которая обновляет данные неясен. Т.е. при попытке update'а незакомиченной записи Ваша транзакция просто подвиснет в ожидании пока завершится незакоммиченная транзакция.
либо транзакция, добавившая потребителя, еще не была завершена
либо потребитель успел поменять email
Скажите, пожалуйста, а зачем в реальной жизни проверять отсутствие записи с заданным FacebookId?
Что мешает сделать это до запуска транзакции с уровнем изоляции read committed/uncommitted?
до того, как нода попадет в балансировщик нагрузки
Если это как-то контроллируется, т.е. если нода не попадает в балансировщик, пока всё окончательно не проинициализируется, то ради чего усложнять? Какая разница, когда она попадёт в балансировщик (если, конечно, речь не о десятках минут инициализации)?
Дело в том, что Вы разложили «неэффективный» предикат в «эффективный» путем обозначения границ. Таким же образом это сделал бы оптимизатор запросов.
Вы это сделали с рассчетом на то в какой именно запрос выльется. С другой стороны Вы же говорите, что закладываться на то, каким получится запрос нельзя, ибо провайдер непредсказуем. Нестыковочка получается…
WHERE cast(CreatedOn as Date) = cast(GETDATE() as Date)
Естественно ни одни индекс не сможет оптимизировать такую выборку и будет полный обход таблицы.
Вы удивитесь, но в MS SQL Server обхода таблицы не будет — посмотрите план выполнения, будет Index Seek (я сейчас говорю не про XXX to Database, а про чистый T-SQL который вы написали).
Простите за оффтопик, параллельно чтению Вашей статьи наткнулся на новость о модели космического корабля весом 300-500кг. Это бред, который был перепечатан всеми русскими СМИ или они действительно могли сделать корабль массой меньше, чем жигули?
Если серверов несколько, то выдаваемый устройству IP адрес будет делом случая (даже при использовании резервирования).
Если на каком-либо оборудовании есть настройки завязанные на конкретный IP адрес, то тут возникнет проблема…
Это самое «худшее» может быть сильно критичным, если для ряда сервисов наружу дан доступ на маршрутизаторе по IP (IP съедут, доступ, соответственнно, тоже).
Также, настраиваться может и не минуты (множество VLAN'ов, соответственно множество scope с различными отдаваемыми по DHCP Option XXX и т.д.)…
Хотел уже было поругаться с Росреестром, который не принимает мою ЭЦП из за отсутствия в ней соответствующего OID-а, однако, более детальное изучение закона подсказало, что этот запрет вступает в силу только 08.07.2016…
1. если платежку приности юридическое лицо (на бумаге или в банк-клиент), то какой там КБК написан, с таким и отправим — у нас нет опции изменять реквизиты, у нас нет оснований отказывать в приеме платежки. Банки не в состоянии брать на себя миссию убеждения бухгалтеров, которые составляют платежки, в том, что они неправильно это делают.
2. п.1 в той же мере относится и к физическим лицам, однако, как правило, они не имеют банковского счета и приходят не с готовой платежкой, а с реквизитами (на клочке бумаги, на квитанции по форме ПД-4 и т.п.). Большая часть клиентов приходят с квитанцией по форме ПД-4. Эти квитанции в большинстве своём заполнены получателем платежа (администратором дохода). Здесь наши руки тоже связаны — клиент понятия не имеет что на этой квитанции написано (кроме суммы и общего представления за что именно он платит), а миссия убеждения банками бухгалтеров администраторов доходов ещё менее реализуема, чем в п.1
В любом случае, наличие открытого перечня КБК будет лучше, чем его отсутствие, так что спасибо Вам за Ваше начинание.
Какие-то очень странные цифры… что за сервера такие за 180 млн рублей каждый?
Касательно заполненных блейд-шасси — тоже интересно где такие цены? (даже учитывая вторую звёздочку — по состоянию на полгода назад)… в моём понимании за 800 тыс. с натяжкой (без резервирования сети и FC) можно купить пустое шасси. А туда нужно ещё лезвия докупать (10-16-32 штук, по стоимости от 250 тыс. до 1 млн. каждое).
Вы не сможете эту запись обновить пока транзакция, добавившая потребителя не завершится. Профит от проверки в транзакции, которая обновляет данные неясен. Т.е. при попытке update'а незакомиченной записи Ваша транзакция просто подвиснет в ожидании пока завершится незакоммиченная транзакция.
Проверьте ROWCOUNT после обновления.
Что мешает сделать это до запуска транзакции с уровнем изоляции read committed/uncommitted?
lazerto.com/?q=won%27t
lazerto.com/?q=can%27t
Ринет, Москва — imarker не используется.
Если это как-то контроллируется, т.е. если нода не попадает в балансировщик, пока всё окончательно не проинициализируется, то ради чего усложнять? Какая разница, когда она попадёт в балансировщик (если, конечно, речь не о десятках минут инициализации)?
Вы это сделали с рассчетом на то в какой именно запрос выльется. С другой стороны Вы же говорите, что закладываться на то, каким получится запрос нельзя, ибо провайдер непредсказуем. Нестыковочка получается…
Вы удивитесь, но в MS SQL Server обхода таблицы не будет — посмотрите план выполнения, будет Index Seek (я сейчас говорю не про XXX to Database, а про чистый T-SQL который вы написали).
Если на каком-либо оборудовании есть настройки завязанные на конкретный IP адрес, то тут возникнет проблема…
Также, настраиваться может и не минуты (множество VLAN'ов, соответственно множество scope с различными отдаваемыми по DHCP Option XXX и т.д.)…
Зря Вы недооцениваете падение DHCP :-)