Здравствуйте, BrainSlug, Вы писали:
V>>Потому что ssh, бро. Потому что всю работу делает ssl, а ssh — это просто высокоуровневый "клей" такой, соблюдающий некий свой простенький протокол через отнюдь не простенький ssl. BS>я не о том. я не понял, в чем был аргумент про ssl в контексте винды?
Там вечные проблемы с контекстом безопасности и авторизацией
Я указал на то, что ключи SSH можно хранить как душе угодно для конкретного приложения. В Линухах это просто файлы в некоторой директории. Т.е., это не проблема виндов, а проблема конкретного приложения, в каком виде оно хранит ключи шифрования.
Ну и такой момент, что в виндах более популярны другие способы организации безопасности, например, можно юзать централизовано предоставленный для всех приложений Kerberos или AD. Т.е. тащить прямую кальку с линухов в винды — не самое умное занятие.
V>>Это на практике. BS>на практике у меня были периодически проблемы с утилитами из cygwin с путями, с кодировками и прочей ерундой, которой не было на линухах. это, конечно, не проблема винды. это проблема кривости именно сборок cygwin. но от этого не легче.
А, я думал речь про ssh вообще. Ну так не пользуй cygwin. Проблема с кодировками в виндах ровно одна — это потенциальное наличие ДВУХ различных кодировок шрифтов по-умолчанию для консоли (cmd.exe) и для остального ГУИ. Поэтому, первым делом при запуске консоли надо устанавливать для неё кодировку её шрифта. Собсно, в PuTTy такие настройки есть.
Ну или пользоваться юникодными версиями программ.
V>>Потому что решение ssh + powershell уже есть прямо сейчас. V>>Всё это хоть и доступно прямо сейчас, но требует примерно столько же телодвижений, как на линухах. BS>пример плиз. только не на порт, который ручками надо еще полдня настраивать и т.п. статья какая-нибудь, где как раз + powershell будет.
Зачем тебе статья? Это же просто удалённая консоль. Запусти в ней консольную программу на удалённом хосте.
Или еще круче: бери какой-нить ssh nuget и прямо из power shell можешь куда-то установить соединение, что там выполнить, получить результат и закрыть это соединение. Всё на автомате, как и в линухах. Вот пример для одной из либ:
using (var client = new SshClient("hostnameOrIp", "username", "password"))
{
client.Connect();
client.RunCommand("etc/init.d/networking restart");
client.Disconnect();
}
Переведи сей сниппет на PS.
V>>Насколько я понял, они хотят, чтобы все эти операции уже были сделаны без участия клиента, а только лишь нажиманием мышкой на какую-нить галочку в списке установленных компонент windows + удобный ГУИ конфигурирования сервиса. В выделенном вся суть. Лентяи, угу. )) BS>да нет, не лентяи. как я и думал, они хотят сделать нормальную интеграцию, которая будет работать без вспоминания чей-то матери.
Я ж не против такой интерпретации вещей. ))
Да, именно так. Потому что в стиле линухов — это конфигурирование ручками всего и вся под непременные вспоминания чьих-то матерей. И в таком стиле (и даже лучше) — уже есть прямо сейчас. Действительно, серверов ssh под винды полно — как бесплатных, так и коммерческих.
Здравствуйте, alex_public, Вы писали:
_>Так тебе как раз тут и говорят, что создание в 2000-ом году непараметрических коллекций — это тупая идея, которую наверняка скопировали.
Дык, у MS была своя джава-машина и первый вариант дотнета — это ровно она же отрефакторенная и чуть улучшенная. ))
Дотнет не на пустом месте появился и не просто так. Не доставали бы MS судами, она бы работала в копилку джавы. Ну а нет, так нет.
Здравствуйте, velkin, Вы писали:
V>Какая-нибудь фирма сделала на него ставку, вложила деньги, обучила специалистов, а Microsoft взяла и выпилила свою поделку из своей же операционки. А где гарантия, что подобное не повторится.
Разработанный код и изученное АПИ никуда не делось, просто XNA больше не является самостоятельным продуктом, его составные части (XAudio2, XInput, DirectXMath) были включены в состав системных библиотек под Windows app market. Почти вся графика в XNA писалась на дотнетной обертке DirectX и эта часть тоже никуда не делась из Windows 8, всё ОК.
Просто надо понимать, что есть XNA — это просто аббревиатура, которая объединяет несколько относительно независимых технологий.
Ну разве что выход DX12 сделал прошлые технологии устаревшими. Не потому, что прошлые технологии испортились, а потому что DX12 резко лучше. ))
====
Например:
XAudio2 version 2.8 ships today as a system component in Windows 8, XAUDIO2_8.DLL. It is available “inbox” and does not require redistribution with an app. We recommend to use the Windows Software Development Kit (SDK) for Windows 8 to develop against XAudio2; the Windows SDK for Windows 8 contains the necessary header and import library for statically linking against XAUDIO2_8.DLL.
Здравствуйте, vdimas, Вы писали:
C>>И таких задач достаточно много. V>Что говорит лишь о том, что масштабируемость в линухах минимум такая: на каждый инстанс системы/кластера по разработчику (или команде). Т.е. без полноценного прикреплённого разраба (или нескольких) никакая боевая линуховая система не живёт.
Странно, что в Гугле нет примерно нескольких миллионов админов.
V>И это так и есть, мы общаемся с нашими линуховыми клиентами — это общепринятая практика.
Бабой Маней и бабой Ваней из соседнего ларька?
V>В виндах, ес-но, другой принцип: на разработчика (команду) будет куча инстансов, про которые разработчик даже и не в курсе.
Нет, не будет.
V>Вовсе не поэтому. Когда складывалась культура современных крупных систем, дотнета еще не было или он только-только появился со всеми своими детскими болезнями. Джаву тоже первые ~5 лет всерьёз не воспринимали, пока Оракл не интегрировал её в свои серваки, кста, где-то в конце 90-х.
Как именно "интегрировал"? Встроил в CPU?
LOL.
V>С этой джавой Sun выглядит как мифический Данко — разработала технологию за свой счёт, бесплатно отдала её людям и красиво сдохла. )) V>MS дохнуть не собирается, вестимо. ))
Собирается, собирается.
Здравствуйте, vdimas, Вы писали:
V>Почему? Есть задача, вот решение.
Потому, что это не решение.
C>>Ага, суперудобно. V>Как и везде. V>Например, чтобы твой ssh-клиент подключился к ssh-серваку, на ём тоже должен быть установлен совместимый с версией клиента демон ssh. А как иначе?
Я вот не поленился и взял Putty образца 2005-го года. Оно работает с моим сервером, который на Ubuntu 15.10.
Т.е. совместимость в 10 лет, как минимум, между разными ОС.
V>И с этой совместимостью на сегодня тоже имеются заметные траблы, бо стандарты ssl резко расширялись еще буквально 5 лет назад, а системы на линухах зачастую "один раз настроили и они 10 лет работают". Вот такой линуховый маразм, однако.
Опять говоришь из попы. Последние существенные изменения в SSH были в 2006-м году, и даже до этого SSH был де-факто совместим между всеми.
Здравствуйте, vdimas, Вы писали:
C>>К нему ещё бы инфраструктуру открытых ключей, нормальный PAM, SSH и будет... эээ... Линукс. C>>Собственно, даже до MS это дошло: https://blogs.msdn.microsoft.com/powershell/2015/06/03/looking-forward-microsoft-support-for-secure-shell-ssh/ V>А при чем тут вообще MS?
Притом. К ней нужен для нормальной работы механизм PAM и интеграция с утиллитами.
C>>Ещё раз повторю, что главное достоинство инфраструктуры Linux и Java — в их относительной прозрачности. V>В виндах всё возможно аналогично, особенно показанное тобой. Тебе же русским языком сказали — не пользуют не от того, что под виндой нет аналогичных перечисленных тобой возможностей, а потому что есть другие и перечисленное тобой пользовать банально глупо.
Ну так и мне не могут сказать как сделать аналог того, что нужно. То какие-то Dataflow, то psexec предлагают переписать.
V>Аааа... наверно потому что полные аналоги линуксовых SSH-сервисов под винды требуют ровно такого же траха с их настройкой, как под линукс? А ленивым кастомерам, грубо говоря, нужна кнопка "сделать мне хорошо", поэтому-то и нужен MS для, казалось бы, давно решенной в стиле Линукс задачи, не? ))
Какие именно трахи в настройке SSH под Линукс?
V>Для примера, чтобы создать корневой сертификат SSL, пару ключей и подписать их, в Линукс надо выполнить 5-7 команд из командной строки.
Опять двойка. Для SSH не нужно корневых сертификатов.
C>>Это совсем не аналоги JMX-консоли. V>О, опять сакральность поперла. V>JMX — это просто набор явовских библиотек диагностической направленности (ну и как всегда в джаве — с сугубо вербальным описанием требований к интерфейсам объектов MBeans, ы-ы-ы).
Опять двойка.
JMX — это способ подключиться к работающей JVM (включенный по умолчанию, кстати). В Винде аналогом является WMI, но он настолько убог, что даже не смешно.
Здравствуйте, BrainSlug, Вы писали:
C>>Это время прошло. Сейчас рулят системы оркестрации сетей типа BS>т.е. 8-10 лет назад кучей навоза был linux? довольно странно из-за одного кейса называть систему гавном.
10-15 лет назад вообще все ОС были кучей навоза. Были небольшие детские шажки в правильном направлении со стороны Линукса (типа идеи положить /etc в систему контроля версий), но реально фундаментальные изменения начались где-то в районе 2005-го года.
BS>ну не у всех кастомеров собственные облака и ноды.
Те кто сейчас сами занимаются танцами с MCSE-сертифицированным бубном вокруг Одного Большого Сервера — в итоге переедут в облако. Публичное или приватное. Просто из-за того, что в промышленном масштабе производство получается дешевле, чем у кустарей.
Здравствуйте, vdimas, Вы писали:
V>В таком случае, в Линуксах он не интегрирован ни разу, это третьесторонняя для линухов программа. Просто авторы сборки пихают и этот пакет в общую помойку пакетов. Ты собери линукс без готовой чьей-то сборки+репозитория к ней, потом расскажешь, что там и как там "интегрировано". ))
Так я собирал.
И SSH таки интегрирован. Например, есть scp или rsync для копирования файлов. Как там сделать rsync через psexec?
Или как через psexec сделать коммит в git-репозиторий?
C>>В OpenSSH. V>Не пользуй open ssh под виндой, какие проблемы? Возьми другую реализацию ssh-сервиса.
И какую?
C>>Ты, видимо, не знаешь, что SSH и SSL/TLS — это совершенно разные вещи. Ключи SSH никак не связаны с SSL/TLS. V>Т.е. не знаешь, так и запишем. V>А какие ключи у SSL, кста? )) Откуда она их берет? V>Разве SSL самостоятельно управляет ключами? Или некий "высокоуровневый клей", типа SSH, подсовывает эти ключи?
Ну вот ты только что расписался в том, что ни разу не использовал авторизацию по ключам в SSH.
В качестве ликбеза ещё раз повторю — в SSH не используется TLS или SSL. Вообще. Это полностью автономный протокол, который использует (в том числе) свой формат ключей.
C>>Нет, не умеют. Например, разбор пути вечно глючит. V>Опять у open ssh? ))
В том числе.
C>>У меня по этому поводу есть инсайд. В Винде будет сделано ровно как в Линуксе V>Как в Линухе уже есть.
Нету.
C>>даже PAM клятвенно пообещали. V>ОМГ, это г-но мамонта? )) V>А уже возникла такая потребность? V>В виндах SSO работает прекрасно и без PAM.
Ой вей...
PAM — это не механизм single-sign on вообще. Это возможность гибко настраивать действия для авторизации и аутентификации.
V>>>Не зря же расходы на эксплуатацию линухов выходят всегда дороже, хотя покупка — дешевле или даже бесплатна. C>>Это вообще бред. V>Это статистика. Линухи дороже в эксплуатации. Потому что требуют более грамотного (т.е. более дорогого) персонала.
Это в случае Одного Большого Сервера. Который через десяток лет будет интересен только толпе MCSE на пособии по безработице.
C>>Не надо мне рассказывать детские сказки. Есть софт, который НЕ РАБОТАЕТ на другой версии IIS. Просто не работает и всё (Enterprise Vault — I'm looking at you!). V>Ну тогда тебе уже отвечали — виртуализация. На виндовых серверах она сейчас имеет оверхед, близкий к 0-лю, в отличие от линухов, поэтому виртуализация в серверных виндах популярнее, чем в линухах.
Ага, особая такая виртуализация. Через секретные технологии Сколково.
Здравствуйте, Cyberax, Вы писали:
C>>>И таких задач достаточно много. V>>Что говорит лишь о том, что масштабируемость в линухах минимум такая: на каждый инстанс системы/кластера по разработчику (или команде). Т.е. без полноценного прикреплённого разраба (или нескольких) никакая боевая линуховая система не живёт. C>Странно, что в Гугле нет примерно нескольких миллионов админов.
Боюсь, что под каждую одну систему/кластер там есть скорее программисты, чем администраторы, бо в случае линухов эти две специальности слабо различимы. ))
V>>И это так и есть, мы общаемся с нашими линуховыми клиентами — это общепринятая практика. C>Бабой Маней и бабой Ваней из соседнего ларька?
Из JP Morgan к примеру. Не знаю как зовут всех работников там, может Вани тоже есть. ))
V>>В виндах, ес-но, другой принцип: на разработчика (команду) будет куча инстансов, про которые разработчик даже и не в курсе. C>Нет, не будет.
Ага, Баба Яга против. Неприятный факт для линуховодов, дело известное.
V>>Вовсе не поэтому. Когда складывалась культура современных крупных систем, дотнета еще не было или он только-только появился со всеми своими детскими болезнями. Джаву тоже первые ~5 лет всерьёз не воспринимали, пока Оракл не интегрировал её в свои серваки, кста, где-то в конце 90-х. C>Как именно "интегрировал"? Встроил в CPU?
В свою БД как альтернативу/дополнение к PL SQL.
C>LOL.
Ага, я тоже ржал.
V>>С этой джавой Sun выглядит как мифический Данко — разработала технологию за свой счёт, бесплатно отдала её людям и красиво сдохла. )) V>>MS дохнуть не собирается, вестимо. )) C>Собирается, собирается.
Тебе из твоих конкретных линухов виднее. Пока ты одновременно с целым зоопарком линухов не работаешь. А мне из этого зоопарка линухов виднее несколько иное — тотальная ущербность психологии основных игроков, которые не в состоянии договориться о тривиальнейших вещах.
Здравствуйте, BrainSlug, Вы писали:
V>>Да любая умеет, которая умеет и под линукс, хосподя. Консольные утилиты умеют из коробки, бо им пофиг, т.к. просто ввод/вывод для них перенаправляется. А всякие специфические на ssh заточенные умеют через разные сборки cygwin. Тем более, что 99% таких "утилит" — это просто скрипты, ы-ы-ы. BS>это в теории. тут Cyberax прав. (в остальном он показывает не знание винды)
JFYI, на Винде я занимался всем — от драйверов ядерного уровня до создания крупных вычислительных кластеров.
V>Или еще круче: бери какой-нить ssh nuget и прямо из power shell можешь куда-то установить соединение, что там выполнить, получить результат и закрыть это соединение. Всё на автомате, как и в линухах. Вот пример для одной из либ:
RenciSsh(SSH.NET) что ли? (есть еще порт Тамира с java, полное глюкалово) . так это я все знаю. V>
Здравствуйте, Cyberax, Вы писали:
V>>Разве SSL самостоятельно управляет ключами? Или некий "высокоуровневый клей", типа SSH, подсовывает эти ключи? C>Ну вот ты только что расписался в том, что ни разу не использовал авторизацию по ключам в SSH.
Ты на вопрос не ответил.
А я только что расписался в том, что плотно работаю с TLS и SSL. И что характерно — с их реализацией в рамках той самой либы open ssl, которая де-факто стандарт для линухов и от которой зависит твой любимый open ssh.
C>В качестве ликбеза ещё раз повторю — в SSH не используется TLS или SSL. Вообще.
Я говорил про конкретно зависимость open ssh от open ssl. RSA, DSA и еще несколько стандартов шифрования в open ssh реализованы через вызовы open ssl. Перечитай еще раз первую строку процитированного в этом сообщении. Ты с чем споришь? По диагонали читаешь? ))
C>Это полностью автономный протокол, который использует (в том числе) свой формат ключей.
Садись, два. SSH передаёт ключи шифрования низлежащих алгоритмов как "черные ящики", формата которых сам SSH не знает и знать не желает.
Но это, в любом случае, никак не отвечает на вопрос, причем тут ХРАНЕНИЕ ключей произвольной реализацией SSH-сервака/клиента и твои проблемы с конкретным глючным клиентом/сервером SSH? Повторюсь, как эти ключи хранятся — это личное дело конкретной программы (в том числе твоей глючной, которую ты использовал), а вовсе не какая-то непреодолимая беда именно Windows. Это просто попытка обратить твоё внимание на дикую нелогичность твоих "аргументов". Конкретно Windows тут не при чем.
C>>>Нет, не умеют. Например, разбор пути вечно глючит. V>>Опять у open ssh? )) C>В том числе.
А взять одну из десятка-полутора альтернатив религия не позволяет?
C>>>У меня по этому поводу есть инсайд. В Винде будет сделано ровно как в Линуксе V>>Как в Линухе уже есть. C>Нету.
Есть. ))
Продолжаешь выдавать желаемое за действительное.
C>PAM — это не механизм single-sign on вообще. Это возможность гибко настраивать действия для авторизации и аутентификации.
Не надо тут бегать. Этот механизм появился не из воздуха, а именно для реализации XSSO, в кач-ве "плагинной системы" для различных ср-в аутентификации. У PAM одна беда — он не нужен от слова совсем, хотя бы потому, что
с помощью только PAM нельзя реализовать Kerberos — наиболее распространённый тип технологии единого входа, используемый UNIX-системами.
Нужен другой аналогичный стандарт. Т.е. я твоей радости не понимаю.
V>>Это статистика. Линухи дороже в эксплуатации. Потому что требуют более грамотного (т.е. более дорогого) персонала. C>Это в случае Одного Большого Сервера. Который через десяток лет будет интересен только толпе MCSE на пособии по безработице.
Это как обстоят дела на прямо сейчас и как они обстояли все последние лет 20. А как будет через 10 лет ты знать не можешь.
C>>>Не надо мне рассказывать детские сказки. Есть софт, который НЕ РАБОТАЕТ на другой версии IIS. Просто не работает и всё (Enterprise Vault — I'm looking at you!). V>>Ну тогда тебе уже отвечали — виртуализация. На виндовых серверах она сейчас имеет оверхед, близкий к 0-лю, в отличие от линухов, поэтому виртуализация в серверных виндах популярнее, чем в линухах. C>Ага, особая такая виртуализация. Через секретные технологии Сколково.
Да нет. Курить паравиртуализацию и аппаратную паравиртуализацию. Это тебе не QEMU в KVM и VirtualBox. И вообще курить различие технологий виртуализации. Их много.
Просто MS даже выложила исходники модулей ядра и дров для Linux под GPL уже давно, RedHat/CentOS (с версии 5.2) и Suse включают их в свою сборку ядра... в итоге, быстрее всего на сегодняшний день виртуальные линухи работают на мелкомягком Hyper-V и третьестороннем Xen (который не линух ни разу), ы-ы-ы много раз. Ну и от гостевых виндовых Vista/Server 2008 и выше тоже оверхед виртуализации практически не отличим от 0-ля на Hyper-V.
В общем, для случая обработки I/O, особенно сетевого, пропасть м/у Hyper-V и каким-нить наколенными KVM/VirtualBox — бесконечна. Это совершенно разные весовые категории.
Тем временем в Linux:
Ядро Linux 3.14 будет поддерживать новый режим, разработанный Мукешем Разором (Mukesh Rathor)
из корпорации Oracle. Режим аппаратной паравиртуализации (PVH) позволяет гостевой ОС использовать аппаратные возможности платформы, но при этом не требует эмуляции оборудования с помощью QEMU. Это впечатляющий шаг в эволюции паравиртуального режима.
Какое ядро использует RH6.x? Ах, 2.6.32...
А RH7.x? Ах, 3.10...
А когда там ожидается RH8? Ах, примерно к 2020-му году...
При том, что в виндах это с 2007-го года...
Что ж так не везет-то? ))
Да и этот "новый режим", по старой доброй линуховой традиции, еще будут доводить и доводить до стабильного состояния. Опен-сорс он такой, угу. Весьма неторопливый. А сколько еще PVH-дров надо будет разработать... а как туго для линухам даются дрова — это же целая притча во языцех, отдельная тема для нервотрёпки бедных админов. Зато в Виндах с дровами всё ОК, в том числе с PVH-дровами.
C>Самому не смешно?
Конечно смешно, когда кто-то в каждом абзаце натурально не в курсе ничего из обсуждаемого.
Здравствуйте, vdimas, Вы писали:
V>>>Разве SSL самостоятельно управляет ключами? Или некий "высокоуровневый клей", типа SSH, подсовывает эти ключи? C>>Ну вот ты только что расписался в том, что ни разу не использовал авторизацию по ключам в SSH. V>Ты на вопрос не ответил.
Я ответил. Ты просто понятия не имеешь о чем идет речь.
C>>В качестве ликбеза ещё раз повторю — в SSH не используется TLS или SSL. Вообще. V>Я говорил про конкретно зависимость open ssh от open ssl. RSA, DSA и еще несколько стандартов шифрования в open ssh реализованы через вызовы open ssl.
Нет, ты говорил про именно то, что SSH является надстройкой над SSL/TLS.
C>>Это полностью автономный протокол, который использует (в том числе) свой формат ключей. V>Садись, два. SSH передаёт ключи шифрования низлежащих алгоритмов как "черные ящики", формата которых сам SSH не знает и знать не желает.
Спорим на $100? Это немного нечестно, конечно, так как я писал свою реализацию SSH на Rust, но бред уже надоело слушать.
В SSH формат ключей специфицирован в https://tools.ietf.org/html/rfc3447 на который ссылается секция 6.6.
V>Но это, в любом случае, никак не отвечает на вопрос, причем тут ХРАНЕНИЕ ключей произвольной реализацией SSH-сервака/клиента и твои проблемы с конкретным глючным клиентом/сервером SSH?
Слушай, попробуй зайти на Линукс по ключу. Тупо создай виртуалку и зайди туда через SSH, чтобы хоть понимал о чем я говорю.
V>>>Опять у open ssh? )) C>>В том числе. V>А взять одну из десятка-полутора альтернатив религия не позволяет?
Какую именно?
V>Есть. )) V>Продолжаешь выдавать желаемое за действительное. https://www.google.com/search?q=Windows+is+a+dungheap&ie=utf-8&oe=utf-8#q=Windows+is+made+for+idiots+only
C>>PAM — это не механизм single-sign on вообще. Это возможность гибко настраивать действия для авторизации и аутентификации. V>Не надо тут бегать. Этот механизм появился не из воздуха, а именно для реализации XSSO, в кач-ве "плагинной системы" для различных ср-в аутентификации.
PAM — это механизм гибкой авторизации. Он вообще никак не относится к SSO и нужен совершенно для другой цели.
"PAM не поддерживает Kerberos" звучит примерно как "HTTP не поддерживает стирку одежды". Что характерно, оба выражения полностью истинны.
V>У PAM одна беда — он не нужен от слова совсем, хотя бы потому, что V>
V>с помощью только PAM нельзя реализовать Kerberos — наиболее распространённый тип технологии единого входа, используемый UNIX-системами.
V>Нужен другой аналогичный стандарт. Т.е. я твоей радости не понимаю.
Это из Wiki, которую писал школьник Вася?
C>>Это в случае Одного Большого Сервера. Который через десяток лет будет интересен только толпе MCSE на пособии по безработице. V>Это как обстоят дела на прямо сейчас и как они обстояли все последние лет 20. А как будет через 10 лет ты знать не можешь.
Могу. Винды не будет.
C>>Ага, особая такая виртуализация. Через секретные технологии Сколково. V>Да нет. Курить паравиртуализацию и аппаратную паравиртуализацию. Это тебе не QEMU в KVM и VirtualBox. И вообще курить различие технологий виртуализации. Их много.
"Аппаратная паравиртуализация" — LOL!
Для твоего сведения, "паравиртуализация" — это просто возможность запуска модифицированной гостевой ОС. В том числе на железе, не имеющем собственной поддержки аппаратной виртуализации.
V>Просто MS даже выложила исходники модулей ядра и дров для Linux под GPL уже давно, RedHat/CentOS (с версии 5.2) и Suse включают их в свою сборку ядра... в итоге, быстрее всего на сегодняшний день виртуальные линухи работают на мелкомягком Hyper-V и третьестороннем Xen (который не линух ни разу), ы-ы-ы много раз. Ну и от гостевых виндовых Vista/Server 2008 и выше тоже оверхед виртуализации практически не отличим от 0-ля на Hyper-V.
А это уже клинический идиотизм... На 100% и целиком. Каждое предложение просто неправильно.
Здравствуйте, koandrew, Вы писали:
K>Здравствуйте, vsb, Вы писали:
vsb>>Если я правильно понимаю, это не совсем то. Портлеты позволяют использовать совершенно разные компоненты в полной изоляции на одном сайте, на одной странице, причём дают UI для пользователя, с помощью которого он эти компоненты может на этой странице настраивать, упорядочивать и т.д. и всё это идёт из коробки. Рукоблудствовать можно много, но на самом деле чтобы добиться подобного функционала самому, придётся написать очень много кода (к тому же в мире есть определённое число готовых портлетов, которые не придётся писать самому, в случае использования готовой технологии).
K>Ну да, мы все в курсе — абстрактная фабрика абстрактных фабрик для создания абстрактных фабрик: K>Image: jtrac-callstack1.png
K>
Неплохо бы для дот нета такую же картинку для развернутого в IIS web приложения с security, linq и т.п. чтоб посмеяться вместе
"Мы будем уничтожать свое ядерное оружие вместе с Америкой" (c) Б. Ельцин
Здравствуйте, Cyberax, Вы писали:
C>Я ответил. Ты просто понятия не имеешь о чем идет речь.
Ты уже третий раз бегаешь. Еще один раз и будет четыре разрыва. ))
Ты утверждал про некие проблемы с ключами на Windows. Я тебя спрашиваю — кто и как хранит ключи? Я хочу заставить тебя начать думать, чтобы ты сам увидел свой промах в рассуждениях.
А ты в ответ: C>Нет, ты говорил про именно то, что SSH является надстройкой над SSL/TLS.
На рекорд по прыжкам в сторону решил пойти?
Я говорил про то, что SSH является простейшей программой, обслуживающей простейший протокол-"клей". Основная масса работы выполняется алгоритмами шифрования, которые практически всегда идут из open ssl (кроме совсем специфических сценариев, от которых ты далек, ес-но).
Зачем я это упомянул? — чтобы исключить спекуляции, потому что open ssl работает под виндами просто чудесно и огромная туча программ его пользуют. Т.е. проблема где-то еще? Т.е. некая несложная, но при этом глючная прога почему-то не пашет, но виноваты, конечно, винды? Какая прелесть. )) А взять другую прогу из кучи подобных религия не позволяет? ИМХО, тут больше всех религия и виновата.
C>>>Это полностью автономный протокол, который использует (в том числе) свой формат ключей. V>>Садись, два. SSH передаёт ключи шифрования низлежащих алгоритмов как "черные ящики", формата которых сам SSH не знает и знать не желает. C>Спорим на $100?
Если ты решил спорить против выделенного, то я спорю хоть на 100 тыщ $$.
C>Это немного нечестно, конечно, так как я писал свою реализацию SSH на Rust, но бред уже надоело слушать.
Склероз знач у тебя, забыл как сериализацию ключей в сетку делал.
Ы-ы-ы много раз. Это не формат ключа, это формат пакета для ключа, бро. Енвелоп. Тупой заголовок, в котором метка типа ключа, еще пара служебных полей, длина ключа и далее сам ключ, собсно. Вот этот сам ключ рассматривается с т.з. SSH как черный ящик, хотя сам может иметь некую структуру, в зависимости от выбранного алгоритма.
V>>Но это, в любом случае, никак не отвечает на вопрос, причем тут ХРАНЕНИЕ ключей произвольной реализацией SSH-сервака/клиента и твои проблемы с конкретным глючным клиентом/сервером SSH? C>Слушай, попробуй зайти на Линукс по ключу. Тупо создай виртуалку и зайди туда через SSH, чтобы хоть понимал о чем я говорю.
Я регулярно захожу по ключу. Причем, сначала захожу первый раз через SSH с форвардом порта, оттуда опять через SSH (двойная внутренняя сеть у банков и бирж), т.е. дважды в итоге форвардю порт на локальную машину. А потом запускаю прогу локально, а не удалённо. Иногда надо трижды заходить во внутренние подсетки. Но это всё оффтоп, просто ты задолбал детскими понтами на детские темы, выдаваемые за откровения.
Почему бы вместо понтов не перестать бегать от ответа на простые вопросы? Неужели так трудно признать, что сморозил ерунду насчет проблем ssh как такового в винде и не признать, что open ssh — это слабопереносимое УГ? Такое бывает в опенсорсе, не надо этого стыдиться! В опенсорсе никто никому ничем не обязан, глюки являются нормой вещей. А если еще вспомнить, что клиент и демон в open ssh имеют 99% общего кода и ты ДОСТОВЕРНО сталкивался как минимум с одним абсолютно безглючным же клиентом на виндах (хотя бы тем же PuTTY), то лужа твоя совсем глубокая выходит.
А, секта велосипедистов седьмого дня? Извини, не признал сразу...
С этого и надо было начинать, а не отнимать у взрослых дядек время.
Блин, повелся на один из постов, где ты попытался свести обсуждение к техническим моментам, а Штирлиц занервничал и раскрыл себя. ))
C>"Аппаратная паравиртуализация" — LOL!
Т.е. не знаешь.
Наверно потому что изкаробки в Линухах "не интегрировано" (С).
На данный момент стабильная версия гипервизора Xen поддерживает два режима виртуализации. В паравиртуальном режиме (PV) оборудование не эмулируется, и гостевая ОС должна быть специальным образом модифицирована, чтобы работать в таком окружении. Начиная с версии 3.0, ядро Linux поддерживает запуск в паравиртуальном режиме без перекомпиляции со сторонними патчами. Преимущество режима PV в том, что он не требует поддержки аппаратной виртуализации со стороны CPU, а также не тратит вычсилительне ресурсы (иногда весьма значительные) для эмуляции оборудования на шине PCI.
Режим аппаратной виртуализации (HVM) появился в Xen, начиная с версии 3.0 гипервизора, и требует поддержки со стороны оборудования. В этом режиме для эмуляции виртуальных устройств используется QEMU, который весьма неповоротлив даже с паравиртуальными драйверами. Однако со временем поддержка аппаратной виртуализации в оборудовании получила настолько широкое рапространение, что используется даже в CPU ноутбуков. Поэтому у разработчиков возникло желание использовать быстрое переключение контекста исполнения между гипервизором и гостевой ОС и в паравиртуальном режиме, используя возможности оборудования. Так появился новый режим — аппаратная паравиртуализация, который будет доступен в Xen, начиная с версии 4.4.
Ядро Linux 3.14 будет поддерживать новый режим, разработанный Мукешем Разором (Mukesh Rathor)
из корпорации Oracle. Режим аппаратной паравиртуализации (PVH) позволяет гостевой ОС использовать аппаратные возможности платформы, но при этом не требует эмуляции оборудования с помощью QEMU.
В процитированном всё клёво, конечно. Жаль, они лет на ~12 отстают от виндов (RH7 на ядре 3.14 планируется под конец 2019г). В виндах эта техника доступна со времен гостевой Висты и Hyper-V Server 2008. А так-то двигаются в правильном направлении. Ну, не то, чтобы двигаются — плетутся в хвосте, ес-но. Но хоть плетутся куда надо и на том спасибо. Подождем очередные 3-4 года? Ведь подождем же? Религия же разрешает!
C>Для твоего сведения, "паравиртуализация" — это просто возможность запуска модифицированной гостевой ОС.
Т.е., ты тут с эдаким нимбом над головой пишешь ответ и даже не заглянул в интернет? И ничего не ёкнуло, не? ))
Решил совсем добить себя? ))
Весело у вас там в Линухах, как я погляжу. Зашорено всё, дальше собственного репозитария света белого не видите.
С "чистой" паравиртуализацией возилась Xen. Наверно у тебя оттуда "знания"? Дык, они устарели, отрывок про Xen я привел. Эти ребятки, пока один патч делали, ядро уже убежало вперед и клиенты взяли конкурента. И так несколько раз подряд. В итоге, они уже перешли на тот же принцип, что и MS ранее. Почти перешли, потому что им еще много чего дорабатывать до взрослого решения. Ребята повзрослели просто. Те самые студенты из университета-отчизны Xen теперь повзрослели лет на 10.
V>>Просто MS даже выложила исходники модулей ядра и дров для Linux под GPL уже давно, RedHat/CentOS (с версии 5.2) и Suse включают их в свою сборку ядра... в итоге, быстрее всего на сегодняшний день виртуальные линухи работают на мелкомягком Hyper-V и третьестороннем Xen (который не линух ни разу), ы-ы-ы много раз. Ну и от гостевых виндовых Vista/Server 2008 и выше тоже оверхед виртуализации практически не отличим от 0-ля на Hyper-V. C>А это уже клинический идиотизм... На 100% и целиком. Каждое предложение просто неправильно.
Ох, мать...
Описанный подход является одним из самых популярных для серьезной виртуализации последние года 3-4 как минимум. С пробуждением.
Это ж попахивает тем, что ты по факту разводишь своего работодателя на бабки, впаривая ему заведомо худшие технологии и ездя по ушам. При том, что продукты Hyper-V Server 2008, 2012, 2016 абсолютно бесплатные.
Ну ниче.. Линукс он такой, не ты первый, не ты последний. Зоопарк сборок и у каждой туева хуча проблем. В итоге, шаг вправо-влево от сборки — расстрел, выпали в корку. Да и пока с кучей настроек и боков возишься, даже по сторонам взглянуть некогда. И на такой плодородной почве буйным цветом цветет ретроградство и зашоренность. ))
Здравствуйте, Cyberax, Вы писали:
BS>>это в теории. тут Cyberax прав. (в остальном он показывает не знание винды) C>JFYI, на Винде я занимался всем — от драйверов ядерного уровня до создания крупных вычислительных кластеров.
Здравствуйте, vdimas, Вы писали:
C>>Я ответил. Ты просто понятия не имеешь о чем идет речь. V>Ты уже третий раз бегаешь. Еще один раз и будет четыре разрыва. )) V>Ты утверждал про некие проблемы с ключами на Windows. Я тебя спрашиваю — кто и как хранит ключи? Я хочу заставить тебя начать думать, чтобы ты сам увидел свой промах в рассуждениях.
В Линуксе по умолчанию публичный ключи, аутентифицирующие пользователя хранятся в .ssh/authorized_keys. Этот файл можно создать любым способом, в том числе с помощью PAM-модуля в цепочке идентификации.
В Винде отутствует механизм PAM, так что непонятно как динамически взять ключ пользователя, например, из LDAP при логине.
V>А ты в ответ: C>>Нет, ты говорил про именно то, что SSH является надстройкой над SSL/TLS. V>На рекорд по прыжкам в сторону решил пойти? V>Я говорил про то, что SSH является простейшей программой, обслуживающей простейший протокол-"клей".
Ой, не надо врать. Вот цитата:
Это тоже самое, почему сертификат, сохранённый, скажем, одним браузером, никогда не будет использован другим (кроме случая, когда это было предусмотрено разработчиками) — у них у каждого свои хранилища сертификатов и корневых ключей. Аналогично, поставь на всех своих машинах с виндой одинаковый сервис ssh и вперёд. Можешь даже сертификаты у них размножать единообразным способом.
Она означает полное незнание механизмов работы SSH.
V>Основная масса работы выполняется алгоритмами шифрования, которые практически всегда идут из open ssl (кроме совсем специфических сценариев, от которых ты далек, ес-но).
Нет. OpenSSH может не зависеть от libssl вообще. Он использует только libcrypto — реализацию низкоуровневых алгоритмов. Даже формат ключей в SSH полностью свой.
Я писал свою реализацию, которая даже RSA делала вручную.
V>Зачем я это упомянул? — чтобы исключить спекуляции, потому что open ssl работает под виндами просто чудесно и огромная туча программ его пользуют. Т.е. проблема где-то еще?
Да. В том, что SSH не работает.
C>>>>Это полностью автономный протокол, который использует (в том числе) свой формат ключей. V>>>Садись, два. SSH передаёт ключи шифрования низлежащих алгоритмов как "черные ящики", формата которых сам SSH не знает и знать не желает. C>>Спорим на $100? V>Если ты решил спорить против выделенного, то я спорю хоть на 100 тыщ $$.
Ок. Продавай квартиру.
Вот цитата из RFC:
The following public key and/or certificate formats are currently
defined:
Additional key types may be defined, as specified in [SSH-ARCH] and
in [SSH-NUMBERS].
The key type MUST always be explicitly known (from algorithm
negotiation or some other source). It is not normally included in
the key blob.
Certificates and public keys are encoded as follows:
string certificate or public key format identifier
byte[n] key/certificate data
The certificate part may be a zero length string, but a public key is
required. This is the public key that will be used for
authentication. The certificate sequence contained in the
certificate blob can be used to provide authorization.
Public key/certificate formats that do not explicitly specify a
signature format identifier MUST use the public key/certificate
format identifier as the signature identifier.
Signatures are encoded as follows:
string signature format identifier (as specified by the
public key/certificate format)
byte[n] signature blob in format specific encoding.
The "ssh-dss" key format has the following specific encoding:
string "ssh-dss"
mpint p
mpint q
mpint g
mpint y
Here, the 'p', 'q', 'g', and 'y' parameters form the signature key
blob.
....
The "ssh-rsa" key format has the following specific encoding:
string "ssh-rsa"
mpint e
mpint n
Here the 'e' and 'n' parameters form the signature key blob.
Signing and verifying using this key format is performed according to
the RSASSA-PKCS1-v1_5 scheme in [RFC3447] using the SHA-1 hash.
The resulting signature is encoded as follows:
string "ssh-rsa"
string rsa_signature_blob
The value for 'rsa_signature_blob' is encoded as a string containing
s (which is an integer, without lengths or padding, unsigned, and in
network byte order).
...
Как видим, формат ключей, включая их кодировку специфицирован прямо в RFC.
C>>Это немного нечестно, конечно, так как я писал свою реализацию SSH на Rust, но бред уже надоело слушать. V>Склероз знач у тебя, забыл как сериализацию ключей в сетку делал.
По RFC, который его указывает. См. выше.
V>Я регулярно захожу по ключу. Причем, сначала захожу первый раз через SSH с форвардом порта, оттуда опять через SSH (двойная внутренняя сеть у банков и бирж), т.е. дважды в итоге форвардю порт на локальную машину.
Ну так где там SSL?
V>Почему бы вместо понтов не перестать бегать от ответа на простые вопросы? Неужели так трудно признать, что сморозил ерунду насчет проблем ssh как такового в винде и не признать, что open ssh — это слабопереносимое УГ?
Ну так меня же просто опровергнуть — достаточно показать SSH-сервер, который обладает полной функциональностью и интегрирован в Винду. В том числе с поддержкой возможности заходить под разными пользователями, с PAM-ом и прочим.
То что OpenSSH не работает нормально на Винде — я и так знаю.
V>>>А взять одну из десятка-полутора альтернатив религия не позволяет? C>>Какую именно? V>>>Есть. ))
Ну так меня же просто опровергнуть — достаточно показать SSH-сервер, который обладает полной функциональностью и интегрирован в Винду. В том числе с поддержкой возможности заходить под разными пользователями, с PAM-ом и прочим
C>>"Аппаратная паравиртуализация" — LOL! V>Т.е. не знаешь. V>Наверно потому что изкаробки в Линухах "не интегрировано" (С). V>Так появился новый режим — аппаратная паравиртуализация, который будет доступен в Xen, начиная с версии 4.4. V>В процитированном всё клёво, конечно. Жаль, они лет на ~12 отстают от виндов (RH7 на ядре 3.14 планируется под конец 2019г).
Ой вей.... Я скипнул остальной бред. Я реально facepalm сделал себе от него. Ядру 3.14 уже 2 года и RH7 зарелизен уже как год.
Я не знаю откуда школьник на Хабре это бред нашел. В Xen всегда поддерживались виртуальные устройства, которые позволяют гостевой системе напрямую вызывать ресурсы основной системы.
В Линуксе первый такой драйвер был baloon driver, который позволяет гостевой системе отдавать неиспользуемую память мастеру. В 2003-м году: http://lxr.free-electrons.com/source/drivers/xen/balloon.c — в то время, когда виндовый сервер находился на уровне где-то протерозоя и едва только научился быть многоклеточным.
Затем появились другие виртуальные драйверы, включая дисковый IO и сеть: https://lwn.net/Articles/239238/ — в 2007-м году. Примерно когда Microsoft игрался в песочнице в машинки.
Под "аппаратной паравиртуализацией" (термин выдуман автором презентации и нигде больше не распространен) понимается использование прямых вызовов вместо гипервызовов с эмуляцией. Однако, Линукс в виде KVM это поддерживает с 2006-го года: http://wiki.xen.org/wiki/Virtualization_Spectrum#What_about_KVM.3F
Ну а про скорость... KVM побеждает сейчас всех. Сравнивать Hyper-V с KVM на Линуксе — это примерно как примерно Годзилла против Бэмби. VMWare на втором месте по скорости и имеет лучшую пропускную способность IO. Xen подбирается к ним двоим, но пока не такая быстрая.
Ну а Hyper-V тормозит как олигофрен на математической олимпиаде.
Хватит уже демонстрировать воинствующее незнание, а?
Здравствуйте, Cyberax, Вы писали:
C>Ну а Hyper-V тормозит как олигофрен на математической олимпиаде.
По отзывам сисадминов давно уже не тормозит. Тормозила первая версия.
Здравствуйте, _ABC_, Вы писали:
C>>Ну а Hyper-V тормозит как олигофрен на математической олимпиаде. _AB>По отзывам сисадминов давно уже не тормозит. Тормозила первая версия.
Он всё ещё тормозит. Но в последних версиях сильно подтянули IO, так что от него рыдать не так сильно хочется.
Следующий затык у Hyper-V в планировщике. Прерывания в Hyper-V виртуализуются, если процессор не используется эксклюзивно гостевой системой. Ну а виртуализованное прерывание — это в Винде очень тяжеловесная вещь. Потому как только плотность гостей превышает количество CPU, то производительность падает камнем вниз.
Xen и KVM ведут себя намного лучше за счёт более эффективного планирования в Линуксе.
Здравствуйте, Cyberax, Вы писали:
C>В Линуксе по умолчанию публичный ключи, аутентифицирующие пользователя хранятся в .ssh/authorized_keys. Этот файл можно создать любым способом, в том числе с помощью PAM-модуля в цепочке идентификации.
... C>Ой, не надо врать. Вот цитата: C>
C> Это тоже самое, почему сертификат, сохранённый, скажем, одним браузером, никогда не будет использован другим (кроме случая, когда это было предусмотрено разработчиками) — у них у каждого свои хранилища сертификатов и корневых ключей. Аналогично, поставь на всех своих машинах с виндой одинаковый сервис ssh и вперёд. Можешь даже сертификаты у них размножать единообразным способом.
C>Она означает полное незнание механизмов работы SSH.
О, спасибо! Наконец-то я от тебя добился прямого ответа на прямой вопрос.
Так вот, всё это означает непонимание тобой того, что речь идёт конкретно об open ssh и его sshd, а не о Линукс. Т.е., выделенное мною в процитированном — это постыдное заблуждение. ))
Сам open ssh был разработан как альтернатива уже существующим проприетарным решениям на тот момент, коих и сейчас еще хватает и под линукс в том числе. Например, Dropbear SSH или LSH или еще несколько.
Я почему и спрашивал, насколько open ssh "интегрирован" в линукс? — чтобы убедиться, что я правильно понял суть твоих заблуждений. Я понял их правильно, потому что правильный ответ — аж ни на сколько open ssh в Линукс не интегрирован.
Most Linux distributions have OpenSSH as an official package, but a few do not.
Это составители большинства сборок его туда кладут вместе с остальным софтом. Большинства, но не всех. ))
V>>Основная масса работы выполняется алгоритмами шифрования, которые практически всегда идут из open ssl (кроме совсем специфических сценариев, от которых ты далек, ес-но). C>Нет. OpenSSH может не зависеть от libssl вообще. Он использует только libcrypto — реализацию низкоуровневых алгоритмов.
А, ну так мы никогда не договоримся, с таким подходом: тут смотрим, тут не смотрим, тут рыбу заворачиваем. ))
libcrypto — это примерно 88% доли open ssl. На моей машине в виде статической библиотеки в релизе она весит 5.4М, а собсно libssl — 0.8М. ))
C>Даже формат ключей в SSH полностью свой.
Ты имеешь ввиду open ssh формат? Потому что в случае замены open ssh на аналогичный ему lsh:
lsh не использует файл authorized_keys от openssh, а использует своё хранилище публичных ключей. Кроме того сохраняются эти ключи так же в отличном от openssh виде.
Если у вас есть ключ, сгенерированый с помощью openssh то для его использования нужно выполнить следующие действия: первым делом нужно скопировать его на сервер примерно так:
Далее нужно залогиниться на сервер и сконвертировать ключ в пригодный для lsh формат командой:
cat id_rsa.pub | ssh-conv > lsh_key_pub
Всего этого ты, очевидно, не знал.
C>Я писал свою реализацию, которая даже RSA делала вручную.
Ну и зря, потому что по последним версиям SSH-протокола, если склероз не изменяет, там порядка 5-6 рекомендуемых способов шифрования, т.е. ты должен ожидать не только RSA, а сразу большой набор вариантов. Поэтому-то такая зависимость от open ssl, чтобы два раза не вставать. ))
Ладно, что хотел, я от тебя услышал, что нужно показал.
На остальное потом.
