Да. Вы правы, я вынужден согласится. Эта "плюшка" пролетела мимо, жаль. В любом случае, технологически, мы готовы, с другой стороны, тема не про нас.
Как и говорил ранее, не стоит переходить не личности. Прошу, постарайтесь сдерживать эмоциональный накал.
Как связаны кассовая операция и паспортные данные? Прошу пояснить детально.
Далеко не во всех. В некоторых случаях, возврат средств ВООБЩЕ не возможен через ПС. Это все зависит от конкретных ситуаций.
Как я и говорил ранее, никто не требует оригинала паспорта. Требуется средство гарантированной идентификации абонента, не более того. Что именно подходит на эту роль кроме паспорта. Полагаю что хостеры с радостью будут пользоваться иными инструментами, если их можно будет предъявить в суде.
Немного реальной статистики. За последние 9 лет, мы получили более 30 запросов из разнообразных структур. (в основном структуры МВД, но и ФСБ с ихней спецсвязью). Даже блин от полиции на транспорте (когда они еще были). В силу специфики работы БСТМ МВД , им нужен тот кто ответственнен за контент и если в какой то момент мы не сможем показать на конкретного персонажа (абонента), есть не малый шанс остаться крайним по той простой причине что у БСТМ до сих пор нет своего следственного отдела и дела по высокотехнологичным преступлениям до сих пор попадают к следователям по уголовным делам. Давайте ка, попробуйте объяснить следователю который всю жизнь сажал маргиналов, что такое magnet ссылка или хотя бы что такое хеш.
Видимо в вашей жизни еще не было случаев жестких конфликтов с органами, соответственно Вы так легко к этому относитесь. Поверьте, в нашей практике были и суды, и запросы на изъятие информации, и включение перехвата трафика, вплоть до засад (дичь конечно полная). Вытаскивать свое оборудование после экспертизы (хорошо если в качестве эксперта попадется грамотный спец), геморрой не малый.
Пожалуйста, будьте любезны не сводить к абсурду нормальную беседу. Кстати такое (только объем покупки, сумму, карту и тд...) периодически бывает при наружном наблюдении за объектом.
Ключевая фраза: " наличных денежных средств".
Вот тут Вы частично и правы и не правы одновременно. Любое юрлицо имеет полное право требовать паспортные данные для целей исполнения условий договора. Однако Вы абсолютно правы в том что не имеет права требовать персональные данные без соответствующих условий их обработки.
Судя по тексту темы, у ТС в качестве услуги был виртуальный сервер. Однако в настоящий момент это очень спорный вопрос, к каким именно услугам относится виртуальный сервер с доступом в интернет. По мнению РКН - услуги ПД, с отдельной лицензией соответственно, так как клиент имеет канал связи с сетями общего пользования. Услуги ПД в данном случае регулируются уже правилами оказания услуг передачи данных, а они построже чем телематика на порядок. Соответственно хостер оказывается между молотом (клиент) и наковальней (гос. структуры). Для минимизации всех возможных рисков этой деятельности, хостеры пытаются найти оптимальные варианты взаимодействия с абонентами. И свой зад прикрыть и абонента не упустить/подставить. С другой стороны, далеко не факт что у ТС сервер был именно в России.
Не верно!
Если к моменту вступления в силу 54фз (до 3*июля*2016*года) организация имела право не применять кассовые аппараты то она вправе их не применять вплоть до 1 июля 2018г. Однако 27.11.2017 внесены поправки N 337-ФЗ в 54 ФЗ которые позволяют таким организациям не применять их до 1 июля 2019г (продлили еще на год).
Теперь по теме:
Я могу ошибаться, но в некоторых платежных системах, есть ограничения на возврат. При оплате с использованием платежных систем, где платежи перечисляются сразу на расчетный счет абонента, возврат средств:
1) возврат может быть осуществлен только полной суммы.
2) Возврат может быть осуществлен только ДО момента перечисления собранных сумм на расчетный счет оператора.
Однако эти правила не распространяются на компании которые принимают платежи напрямую на свои кошельки и пр, так как такие компании не показывают обороты по кошелькам налоговикам (работа в черную).
Если оператор перечисляет сумму физ.лицу с указанием возврата то он тем самым уменьшает налогооблагаемую базу, что автоматически приводит к излишнему вниманию со стороны налоговиков. Увы. Спорить можно до посинения и крыть друг друга всякими недобрыми словами, тыкать в ЗоЗП и прочее прочее но реальность, она зараза, именно такова.
Требование заявления при возврате, решает эту проблему. Рисковать повышенным вниманием налоговиков из за копеечной суммы возврата, ни одна компания не будет. Если в данном случае поставить на чашу весов, подставиться под анонима или подставиться под налоговую, то я думаю выбор очевиден. Возврат средств анониму априори не возможен, так как никто не мешает любому другому человеку выдать себя за него, и получить эти деньги. Если аноним идет в суд, пишет заявления, и тд, он в любом случае будет вынужден идентифицировать себя, что в конечном итоге, так же даст возможность хостеру вернуть деньги без проблем с налоговиками.
Оператор связи или хостер, в силу своей зависимости от все увеличивающегося внимания органов внутренних дел и иных контролирующих органов в РФ обязан играть по определенным в том числе и неписанным правилам, так как законодательство явно не поспевает за развитием технологий. Требование хостера идентификации клиента вызвано несколькими причинами:
1) некая, хоть и эфемерная но уверенность в том что идентифицированный абонент не будет вести себя "плохо"
2) было что показать контролирующим органам в случае возникновения каких либо последствий от оказания услуг оператором и передать эстафету следствия с себя подальше по цепочке. см N 144-ФЗ (закон об ОРМ)
3) Обеспечение договорных отношений. При этом хостеру по большому счету абсолютно наплевать на персональные данные абонента. Речь идет только об ИДЕНТИФИКАЦИИ абонента как лица которое несет ответственность за действия с использованием оборудования хостера. Никто, в здравом уме, не хочет брать на себя неоплаченный риск.
Не хочу рассуждать на предмет, прав абонент или хостер ибо это в итоге гарантия перехода на личности и отсутствие какого либо конструктива, но иногда, для эффективного решения вопросов к взаимному удовлетворению, нужно четко понимать, как устроен этот мир а не играть роль "яжемать" и кричать на всех углах "Обидели мышку - написали в норку".
Имхо совет абоненту - свяжитесь в хостером, договоритесь об идентификации, Я уверен, на 100%, вернут вам средства без проблем. В вашем случае решение есть, но достичь его можно только методом переговоров а не вайна на форумах.
Успехов.
В свою очередь можем предложить такое решение: https://imserver.ru/
2 проца, 4 Gb Ram, диски 25 гб SSD. - 970 руб/мес.
Сервер сможете собрать/изменить самостоятельно в любое время (процессоры, память, количество дисков и пр.). Онлайн биллинг.
По умолчанию, тест дается на сутки, однако если обратитесь в саппорт, увеличим на нужное количество дней.
Москва. Собственный ЦОД (Colocat).
Специально под Ваш запрос.
Проект IMserver.
Биллинг реального времени. (тарифицируем только то время пока существует сервер).
Самостоятельно, свободно в любое время изменяете конфигурацию сервера (память, процессоры, диски, сеть).
Можете использовать свои сборки ПО. (Доступна загрузка ISO образов дисков)
Серверы в любое время можно клонировать/удалить/добавить. Выбор типов и размеров дисков и их комбинирование. (до 4х дисков на сервер)
Приватные сети. Доступен API для автоматического разворачивания серверов.
Есть возможность создавать собственные шаблоны виртуальных серверов.
Расположение Москва, Россия. Виртуализация KVM. Собственная разработка.
Тестовый период. Работа с юрлицами (полный комплект закрывающих документов).
Средний пинг до Вологды (border.gov35.ru)
973 packets transmitted, 972 received, 0% packet loss, time 7813ms
rtt min/avg/max/mdev = 7.626/8.017/14.916/0.488 ms, ipg/ewma 8.038/7.882 ms
Подробнее тут: https://imserver.ru/
Вот: https://imserver.ru/
API: https://imserver.ru/g_api
Онлайн биллинг. Есть тестовый период.
Павел. С вашего позволения вставлю свои две копейки. Вы пытаетесь смешать зеленое, горячее и ароматное в одном флаконе. Что сильнее, червовый туз или шахматный король? Поймите, есть реалии и мечты ( ХОТЕЛки и МОГУлки). Да, хочется чтобы было гарантированно надежно и дешево. Но гарантии это вообще из области финансов, юридической стороны и управления рисками. Но ни грамма не из техники, от слова вообще...
В реальности же есть такое понятие как энтропия. В данном случае я имею ввиду рост сложности объекта: чем сложнее структура то тем больше вероятность ее отказа растущая по экспоненте. Рост сложности ведет к увеличению стоимости, и росту вероятности сбоев. Что надежнее, карандаш или ручка?
Реальность в настоящий момент такова: Существуют в мире 2 технологии применимые к вашей задаче.
1) Fault Tolerance - Устойчивость к сбоям. Технология позволяющая системам не снижать производительности при отказе любой из частей оборудования. Применяется в космосе, в авиации и всюду где от работы систем зависит жизнь человека. По сути это удваивание и утраивание всех систем включая контролирующие и связные. Но даже при этом 100% гарантий отсутствия сбоев априори никто не даст за исключением пожалуй только маркетологов и страховых компаний, в силу специфики их относительно законного способа отъема денег у населения. Как пример - Ваша виртуальная машина исполняется СРАЗУ на двух или трех узлах одновременно параллельно.
2) Высокая доступность - Технология обеспечивающая ограниченное время восстановления после сбоев. Иначе говоря система перестает работать на какое то регламентированное время и после этого продолжает работать. Пример: Резервное копирование и восстановление. Используется подавляющим большинством обычных хостинговых компаний. С виртуализацией проще: Упал узел, подняли ВМ на другом узле. Время простоя = времени переноса файлов клиента + загрузка ВМ.
Есть еще третий вариант, который пока находится в состоянии разработки и попытках нащупать емкость рынка. Это гиперконвергентные системы. К ним можно отнести технологии распределенных хранилищ, cpu donane, memory donate и так далее... Какие то приблизительные наработки в этой области (sheepdog), но пока очень далекие от реальности, Есть варианты и у коммерческих производителей систем виртуализации но они ну совсем не дешевые, я бы сказал даже категорически не разумные. EMC Isilion, PANASAS, Nutanix и иже с ними.
Вы уж определитесь, сколько стоит Ваша задача. Научитесь для начала управлять рисками. Хотя бы просто рассчитайте их, переведите их во что то осязаемое, в то что можно пощупать а не только подумать, в рубли в конце концов. И на базе этих расчетов вы сможете сделать выводы. Какой из вариантов Вам подходит.
Хотите финансовых гарантий - страхуйтесь.
Хотите быстро взлетать после сбоев - делайте бекапы и пробуйте их развернуть (проводите учения).
Хотите свести вероятность падения к минимуму - пересматривайте бюджеты по экспоненте.
Выбор за Вами.
P/S прошу извинить за много буковок и синтаксис.
По пунктам:
1) - Расположение Москва. (собственный ДЦ);
2) - цифры в случае реселлинга обсуждаются индивидуально (так чтобы интересно было всем сторонам) при этом можно синхронизировать даты оплаты так чтобы у Вас был запас по времени;
3) - Требуем обязательной реакции на абузы, как минимум то что абуза принята к устранению. Затем разбираемся индивидуально с каждой. Паранойей не страдаем, но и не принимаем чернуху. Жалоб от спамхауза не допускаем (сами понимаете почему);
4) - Сетап в течение 15 минут после отмашки, звонка, письма (команды). Сначала сетап, выдача, проверка и только после этого оплата если все это устраивает Вашего клиента. (При необходимости возможно тестирование по желанию уже Вашего клиента для Вас бесплатно). Установка системы по вашим требованиям;
5) - Работаем по наличию на складе. Конфигурации могут быть изменены по совместимости. Можем сделать интерфейс к наличию оборудования на складе. Если чего то не хватает, закупаем.
6) - Реально круглосуточная поддержка 24/7/365 в режиме онлайн. Непосредственно рядом с оборудованием.
7) - Вебмани принимаем через мерчант (Пеймастер). То же самое и с картами. Работаем как с юрлицамми так и с физлицами.
8) - Возможно комбинирование оборудования (установка ваших комплектующих в арендованные серверы при необходимости) для снижения затрат на аренду.
Остальное с радостью расскажу если возникнут дополнительные вопросы.
http://www.colocat.ru/
Телефон: (495) 744-84-88 (круглосуточно)
Email: manager@colocat.ru
Вы шутите? Про процедуру сброса root пароля следует напоминать или понятно от чем речь? Нужно ли рассказывать как в этом режиме руткиты подкладываются?
Вы абсолютно правы насчет кроссплатформенности или кроссбраузерности и уж подавно насчет юзабилити, это действительно нужно...
...однако как всегда удобство с одной стороны, тянет за собой множество проблем с другой.
Реализация VNC (RFB) протокола в QEMU сама по себе очень ограничена. В частности в нем длина пароля ограничена 8ю символами, отсутствует напрочь понятие авторизационной сессии и много других моментов. Однако всего что сказано выше уже с лихвой достаточно для того чтобы не выпускать открытый VNC в паблик. В противном случае, зная порт и IP адрес, можно запросто сбрутить этот пароль. Как вы понимаете, что консольный доступ к серверу в 99 случаях из ста равен получению root доступа. Какая уж тут безопасность.
Как быть? Нужен некий прокси сервер, который обеспечит авторизацию каждого конкретного соединения к VNC. Однако тут есть проблема с протоколом VNC. Штатно, в нем нет понятия сессий (есть но не для всех VNC клиентов и серверов). Соответственно поднять чистый прокси сервер уже не получится (haproxy). Остается один вариант: отказ от протокола VNC в паблике, использование VNC реализации на JS + html5 + websockets, туннелирование его через прокси сервер с контролем разовых уникальных сессий и пропуск соединения непосредственно на ноду. VNC пароль в такой схеме вообще не нужен (как правило) + обертка всего этого в SSL + TLS на транспортном уровне. Именно такая схема реализована в OpenStack.
Как итог: Злодей не может получить доступ к консоли если пользователь не авторизован в панели. Невозможно использовать сессию повторно. Невозможно сбрутить пароль так как подтверждение авторизации имеет таймаут. Но, соответственно получаем минусы:невозможность работы со старыми браузерами, невозможность использования толстых клиентов для прямого соединения.
Можно конечно допилить QEMU на работу с сессиями скажем с AAA серверами (radius, tacacs, AD и т.д). Но по сути это ничего не даст так как существующие клиенты не поддержат сессий. Ну или полностью отказаться от VNC и использовать скажем какой нибудь SPICE или RDP.
На фактор цен для клиентов хостинга влияет множество параметров. Для того чтобы понять почему выполнено то или иное действие, необходимо детально проанализировать деятельность компании.
Да. Стагнация на рынке хостинга (не путать с услугами виртуализации, размещения и аренды) налицо. Но нужно же отдавать себе отчет что как таковой интернет всегда развивается лишь на излишках общества а не как основа. Иначе говоря, если вам нечего есть, вы не будете оплачивать хостинг а пойдете и купите себе в первую очередь батон хлеба и молоко.
Возможные причины снижения ARPU (средний чек):
1) Попытка забрать клиентов у домашних (непрофессиональных, будем политкорректными) хостингов;
2) Наращивание объемов клиентов перед продажей бизнеса если известно что стоимость будет рассчитываться исходя из объема абонентской базы;
3) попытка удержать отток абонентов хостинга вызванный появлением множества сервисов которые де факто заменяют собой сайты как таковые (wix, вконтакт, всякие генераторы хомпейджев, яндекс маркет, и прочие глобализирующие сервисы);
4) попытка стимулировать к покупке услуг хостинга лицами с низким уровнем дохода (школьники, студенты и пр.);
5) попытка удержать клиентов из за фактического снижения свободных средств у клиентов из за ухудшения экономической ситуации в связи с санкциями и прочим мировым бардаком;
6) произведена 100% амортизация оборудования и закуплено новое, в связи с этим появились свободные мощности, которые нужно быстро утилизировать.
Это все далеко не полный список из того что приходит на ум сразу.
Насчет разницы между зарубежными хостингами и Российскими. Многое сказано раньше по этому повторяться не буду а лишь дополню. Не забывайте от разнице между РСБУ и МФСО. Не забывайте о методах налогообложения у нас и за рубежом. Не забывайте об фактическом отсутствии производства коньсюмерской электроники на территории РФ. Все это импорт, таможня, курсовая разница и прочее прочее прочее. Не забывайте о возможностях оффшоров, кредитования и прочего. В России этого почти нет.
Есть компании которые рассчитывают цены исходя из рынка. Есть компании которые рассчитывают цены исходя из затрат и вообще более грамотно бюджетируют свой бизнес. Причем тут уже могут вступать в игру такие вещи как амортизация и кредитование. Есть компании которые на рынке играют ценой а есть те кто играет качеством и объемом включенных услуг, все это зависит исключительно от бизнес модели этих компаний.
Будущее.
Так как рынок хостинга в России как таковой очень мал, он практически не регулируется, причем сами же хостеры всеми силами пытаются снизить попытки влияния регуляторов, (как пример темы нужна или не нужна лицензия) и как следствие, государству ни лучше ни хуже не становится от того как себя чувствуют сами хостеры, что закономерно. Потеря всего рынка хостинга в РФ, для РФ как "слону дробина". Так как рынок де факто, дикий и каждый хостер борется за жизнь любыми доступными методами не гнушаясь ничего, распихивая соседей по "психбольнице" локтями, ради того чтобы черпануть священного пойла, ложкой с дырками из общего котла - консолидация невозможна. Соответственно как следствие - вымирание мелких хостеров, и повышение стоимости "входного билета" на рынок. Что в свою очередь приведет к повышению качества услуг, появлению новых плюшек, так как будут драться за каждого клиента уже крупняк. Самоорганизация хостеров в нынешнем виде, практически невозможна в связи с низкой маржинальностю этого бизнеса как такового. Это если исключить как таковое влияние западных компаний на рынок в РФ. Если не исключать, то ситуация ухудшается демпингом зарубежных хостеров и их представителей в РФ.
Ну или Российские хостеры все таки одумаются, и начнут сами укрупняться методом экстенсивного роста. Но тут уже нужны очень немалые капиталы.
Вышесказанное можно описать одной фразой. "Чтобы появилось что то новое, что то старое должно сдохнуть".
Все вышесказанное лишь имхо. Прошу больно не пинать...
