В Харькове нет месячных проездных, но даже если его скопировать — думаете сложно вычислить если один проездной засветится в течении 20 минут в другом конце города?
Нужно тогда контролировать, чтобы один номер не светился одновременно (около 20 минут например) на нескольких станциях. Если с одной копией и разными «маршрутами на работу» это можно сделать и объяснить при необходимости (курьерская работа например), то при большЕм кол-ве копий аномалия выявится быстро.
Необязательно делать глобальную быструю сеть.
Харьковский метрополитен, например, имеет по одному «серверу» на станцию. Сервера синхронизируют свое состояние раз в день (ночью) между центральным сервером. Если были какие-то проблемы или несоответствия по карточке — то она блокируется, в момент синхронизации, на всех станциях.
Также каждый тип карты (обычная, пенсионная, студенческая, с нулем на балансе и т.п.) заставляет пищать автомат по-особенному (а в новых — и RGB диоды разным цветом) — на что очень живо реагируют менты, которые дежурят возле автоматов.
Да и сам автомат по-умолчанию «не пропустит» карту если будет какой-то сбой. У меня так много раз списывало денег, а не пускало — тогда работники метрополитена забирают карту, проверяют транзакции, извиняются и пропускают мимо турникетов :)
Так что с «исправленной» картой в харьковском метрополитене ходить, в лучшем случае, один день получится.
В Киеве карты появились раньше — сомневаюсь что Харьков с нуля разрабатывал систему. Поэтому в Киеве должно быть что-то подобное.
Всех пока устроит 2 :) Много систем в продакшене на RHEL5 и производных — питон 2.4, а новый RHEL6 перешел только на 2.6.
А учитывая десятилетний lifecycle этих систем — Python 2.x еще долго будет жить.
Не стоит забывать и про Solaris. в 10й версии только 2.4 в поставке, для Solaris 11 доступны 2.4/2.5/2.6…
Т.е. как бы не хотелю люди начать использовать версию 3.x — все упирается в отсутствие этой версии в продакшене.
ЗЫ. На десктопе стоит и 2.х и 3.х версии, но сколько бы не пробовал новую версию все равно вынуждет следовать версии 2.4, так как продакшн.
Эт точно. Только что архивил и отсылал на анализ лог 19Гб от одного сервиса за один день, а центральный сислог впахивает как проклятый так как на него не один сервис такой пишет. Уже нужно рассматривать другие альтернативы или распределенные сервера.
Ага, разобрался. Таки чтение RFC помогает :)
В основе DNSSEC SSL тоже лежит «root CA», просто в данном случае он называется trusted-key от корневой зоны.
Для того, чтобы научить утилиту dig проверять подпись, необходимо создать отправную точку в цепочке доверия, создав файл с ключом корневой зоны
Клиент содержит в себе этот ключ и может проверить всю встроенную цепочку. Так как хеши нижних зон (DS записи) подписываются ключем верхних — то «поддельную» цепочку просто нельзя сделать — нет приватного ключа верхней зоны. Т.е. подделать paypal.com, к примеру, будет нельзя, так как нет приватного ключа com зоны для подписи DS записи для paypal.com и клиент сразу увидит несоответствие. Да и сам домен подписывается приватным ключем SSL, поэтому «слить» цепочку с оригинального домена и подставить в свой сертификат не получится.
Таким образом валидность домена из сертификата однозначно подтверждается через «root CA» зашитого в клиенте (в случае если он не может получить его из резолвера) и проверкой подписи конечного домена самим сертификатом.
По поводу фишинга автор тоже говорит что да, есть такое дело :) И нужно использовать нормальные сертификаты для подтверждения «правового статутса».
Про валидность сертификата понял. Но все равно не понял как это поможет доверять сертификату, если не опираться на что-либо еще — так как фишинг сайт будет иметь такой же валидный, с точки зрения DNSSEC, сертификат.
И добавление «тем клиентам, которые не поддерживают» — а что в таком случае мешает заспуфить DNS (ведь клиент не поддерживает DNSSEC, а значит все возможно) и перенаправить на сайт с DNSSEC SSL в котором есть «поддельная цепочка» (клиент это проверить не может) — клиент попадет на сайт, с «валидным» SSL и будет уверен что все в порядке. Это даже удобнее чем покупать корневой CA SSL, ИМХО :)
Т.е. если сам клиент не поддерживает DNSSEC изначально, то грош цена этому SSL.
А вот если клиент пришел на сайт через DNSSEC — тут он может быть уверен что итак попал на нужный сайт и проверил валидность SSL стандартным способом через CA и дополнительно проверил какой-нить extension подписанный ключем DNSSEC сайта — тогда 100% на валидном сайте (так как ключ есть только у владельца зоны).
Без последней проверки все еще будет возможно ISP перенаправить 443 порт на свой сервер (со своим валидным CA).
Но фишинг это никак не затрагивает, у них появится возможность делать валидные сертификаты… Так что вторая проверка из другого источника просто необходима.
Так а зачем тогда такая подпись если она «то валидная, то нет»? Пользователь забьет на это быстро и поставит галочку «доверять всем».
А если такая чехарда случится с сертификатами того же paypal.com, то фишинговым сайтам аля paypa1.com будет существенно легче вызвать доверие — их сертификат будет таким же «не валидным» как и оригинальный :)
Имхо максисмум как вспомогательная технология, когда валидность можно однозначно проверить другим путем. Ну или может допилят, чтобы оно цепочку учитывала и фишеров не пропускало…
Для них логично. Если Megaupload заявляет что их деятельность законна, то их законно спрашивают — а где же налоги?
Т.е. если развалится обвинение в пиратстве, то сыграют налоги и показательный процесс состоится все равно.
Статический адрес еще нужен при сложных конфигурациях хоста. Например если на хосте крутится XEN с виртуальными машинами в bridge и с получением адреса по DHCP. В этом случае адрес AMT может «прыгать» вслед за виртуальными машинами :( и нужна статическая конфигурация.
Хорошая штука для использования в корпоративной среде, например. Жаль что VNC функциональность (Intel AMT KVM) доступна только начиная с AMT 6.0, для чипсетов выше Q67 и только если у процессора есть встроенный GPU.
Более старые чипсеты или CPU без GPU поддерживают только Serial-over-LAN (удобно если лины, grub и консоль туда завернуть) и удаленное управление питанием (с вебкой естественно).
А так получается идеальный Remote Assistance без разделения на вендора и версии OS. Ну и ходить никуда не нужно чтобы ребутнуть машину :)
Не прийдется. Сетевая карта слушает всегда. На счет «можно пинговать» — да, можно, если разрешить в настройках. Если не разрешить, то выключенный комп на пинг отзываться не будет, но свой порт (16992) слушать будет.
Пользую такое дома (Q45 чипсет) — очень удобно иногда ребутить машину в другой комнате или получить доступ к консоли на Serial порту.
Если сравнивать с предыдущей версией, то «юзабилити» и стабильность существенно повысились. Много софта из Application Manager ставится без ошибок. Firefox 3.6 наконец-то начал нормально работать.
Уже можно некоторые некоторые повседневные задачи переносить из wine/windows в reactos.
Я, конечно, всё-таки задумываюсь о реалистичности «слитой» иранцами картины. Всё-таки по основному образованию я радиоэлектронщик, ещё и военный. Мне так кажется, что GPS-приёмники таких машин как RQ-170 должны мягко говоря немного отличаться от своих гражданских собратьев. Например, анттенной системой. По логике, у них должна быть антенна с синтезированной апертурой (антенная решётка), позволяющая искать GPS-спутники узкими лепестками диаграммы направленности. В таком случае эффективно поставить помеху GPS-приёмнику летящего дрона можно только из верхней полусферы, с самолёта-постановщика помех. Потому что антенна смотрит вверх, а добиться незначительных боковых и тем более задних (в конкретном пример — нижних) лепестков диаграммы направленности можно, это не rocket science давно. Это всё просто логичные допущения, ничего общего с реальностью не имеющие, но по логике вещей иранцы должны были обманывать дрон не с земли, а именно из верхней полусферы. С самолёта. При этом им нужны были точные реальные координаты дрона, чтобы липовыми GPS-координатами не уронить машину или не «воткнуть» её в какую-нибудь неподходящую гору. Стало быть, дрон должен был сопровождаться радиолокационными станциями. А он стелс. И габариты его невелики для эффективного обнаружения станциями дециметрового и метрового диапазонов, в которых стелс-технология практически не работает. Но всё же и обнаружение, и сопровождение такого дрона возможны. Равно как и, потенциально, возможен обман его системы навигации (неужели он использует только GPS? в военных системах такое невозможно принципиально — GPS, по логике, должен использоваться изредка для коррекции инерциальной системы навигации, полюс обязаны применяться и прочие способы коррекции, отработанные на системах управления крылатых ракет, например, но это всё логика...).
Там похоже проблема в QEMU — иногда частота проца показывается 0 Hz. Судя по всему виндовый QEMU этим страдает стабильно, а линовые — в зависимости от сборки и наличия/использования KVM. Так же похожие проблемы получал если добавлял '--enable-debug' при сборке QEMU. Сейчас сижу на 0.14 собранном без модификаций, из портов, на Gentoo x64 — полет нормальный.
Как доделаю те фичи которые хочу получить от эмулятора — займусь проверкой на различных платформах и VM — выложу еще и на хабре статью.
По теме: для этих же целей использую полное логирование bash в syslog на удаленный сервер (для 3.х нужен патч, в 4.х уже есть в исходниках)
Нужно тогда контролировать, чтобы один номер не светился одновременно (около 20 минут например) на нескольких станциях. Если с одной копией и разными «маршрутами на работу» это можно сделать и объяснить при необходимости (курьерская работа например), то при большЕм кол-ве копий аномалия выявится быстро.
Харьковский метрополитен, например, имеет по одному «серверу» на станцию. Сервера синхронизируют свое состояние раз в день (ночью) между центральным сервером. Если были какие-то проблемы или несоответствия по карточке — то она блокируется, в момент синхронизации, на всех станциях.
Также каждый тип карты (обычная, пенсионная, студенческая, с нулем на балансе и т.п.) заставляет пищать автомат по-особенному (а в новых — и RGB диоды разным цветом) — на что очень живо реагируют менты, которые дежурят возле автоматов.
Да и сам автомат по-умолчанию «не пропустит» карту если будет какой-то сбой. У меня так много раз списывало денег, а не пускало — тогда работники метрополитена забирают карту, проверяют транзакции, извиняются и пропускают мимо турникетов :)
Так что с «исправленной» картой в харьковском метрополитене ходить, в лучшем случае, один день получится.
В Киеве карты появились раньше — сомневаюсь что Харьков с нуля разрабатывал систему. Поэтому в Киеве должно быть что-то подобное.
А учитывая десятилетний lifecycle этих систем — Python 2.x еще долго будет жить.
Не стоит забывать и про Solaris. в 10й версии только 2.4 в поставке, для Solaris 11 доступны 2.4/2.5/2.6…
Т.е. как бы не хотелю люди начать использовать версию 3.x — все упирается в отсутствие этой версии в продакшене.
ЗЫ. На десктопе стоит и 2.х и 3.х версии, но сколько бы не пробовал новую версию все равно вынуждет следовать версии 2.4, так как продакшн.
Ну и область использования пока только «крупные локальные сети использующие Chrome» как очертил автор :)
В основе DNSSEC SSL тоже лежит «root CA», просто в данном случае он называется trusted-key от корневой зоны.
Клиент содержит в себе этот ключ и может проверить всю встроенную цепочку. Так как хеши нижних зон (DS записи) подписываются ключем верхних — то «поддельную» цепочку просто нельзя сделать — нет приватного ключа верхней зоны. Т.е. подделать paypal.com, к примеру, будет нельзя, так как нет приватного ключа com зоны для подписи DS записи для paypal.com и клиент сразу увидит несоответствие. Да и сам домен подписывается приватным ключем SSL, поэтому «слить» цепочку с оригинального домена и подставить в свой сертификат не получится.
Таким образом валидность домена из сертификата однозначно подтверждается через «root CA» зашитого в клиенте (в случае если он не может получить его из резолвера) и проверкой подписи конечного домена самим сертификатом.
По поводу фишинга автор тоже говорит что да, есть такое дело :) И нужно использовать нормальные сертификаты для подтверждения «правового статутса».
И добавление «тем клиентам, которые не поддерживают» — а что в таком случае мешает заспуфить DNS (ведь клиент не поддерживает DNSSEC, а значит все возможно) и перенаправить на сайт с DNSSEC SSL в котором есть «поддельная цепочка» (клиент это проверить не может) — клиент попадет на сайт, с «валидным» SSL и будет уверен что все в порядке. Это даже удобнее чем покупать корневой CA SSL, ИМХО :)
Т.е. если сам клиент не поддерживает DNSSEC изначально, то грош цена этому SSL.
А вот если клиент пришел на сайт через DNSSEC — тут он может быть уверен что итак попал на нужный сайт и проверил валидность SSL стандартным способом через CA и дополнительно проверил какой-нить extension подписанный ключем DNSSEC сайта — тогда 100% на валидном сайте (так как ключ есть только у владельца зоны).
Без последней проверки все еще будет возможно ISP перенаправить 443 порт на свой сервер (со своим валидным CA).
Но фишинг это никак не затрагивает, у них появится возможность делать валидные сертификаты… Так что вторая проверка из другого источника просто необходима.
А если такая чехарда случится с сертификатами того же paypal.com, то фишинговым сайтам аля paypa1.com будет существенно легче вызвать доверие — их сертификат будет таким же «не валидным» как и оригинальный :)
Имхо максисмум как вспомогательная технология, когда валидность можно однозначно проверить другим путем. Ну или может допилят, чтобы оно цепочку учитывала и фишеров не пропускало…
(пока еще висит в Features на главной):
Т.е. если развалится обвинение в пиратстве, то сыграют налоги и показательный процесс состоится все равно.
Более старые чипсеты или CPU без GPU поддерживают только Serial-over-LAN (удобно если лины, grub и консоль туда завернуть) и удаленное управление питанием (с вебкой естественно).
А так получается идеальный Remote Assistance без разделения на вендора и версии OS. Ну и ходить никуда не нужно чтобы ребутнуть машину :)
Пользую такое дома (Q45 чипсет) — очень удобно иногда ребутить машину в другой комнате или получить доступ к консоли на Serial порту.
Уже можно некоторые некоторые повседневные задачи переносить из wine/windows в reactos.
Как доделаю те фичи которые хочу получить от эмулятора — займусь проверкой на различных платформах и VM — выложу еще и на хабре статью.