Всем спасибо за комментарии. Я полностью согласен, что питоновские фреймворки обычно подразумевают несколько более высокую квалификацию, чем "нажать кнопочку". И для них актуальнее VPS. Что у нас ставят клиенты на VPS у нас статистики нет (кроме тех серверов, что мы сдаем с системным администрированием). Но вот на виртуальном хостинге Django, Zope и другие фреймворки на Python мы поддерживали всегда. Но если раньше максимум что нужно было - это разные версии Python (так же как с PHP) - то есть запросы и по развертыванию Django. На виртуальном хостинге, на самом деле, оно отлично работает. У разработчика нет головной боли с настройкой и администрированием сервера, что уже не мало. Ну и ресурсов на виртуальном хостинге доступно прилично, за 150 рублей такую VPS не купишь.
Что же до тех, кто только разбирается в работе с Django - то это клиенты, им тоже помогать надо ) Понятно, что эта инструкция или включение в панели нужны далеко не всем питонистам.
Я же не спорю, что мнение производителя/правообладателя важнее, прежде всего с точки зрения закона. Проблема законодательства в том, что оно позволяет правообладателю (производителю) требовать блокировки от хостера (на вполне законном основании и под реальной угрозой санкций), а не решать с нарушителем вопрос через суд.
Я поднял одно дело, с относительно хорошим концом. В качестве реальной иллюстрации последствий нарушения хостером требования о блокировке от правообладателя.
Вкратце, правообладатель официально потребовал у хостера блокировку. Хостер выполнил требование. Владелец сайта не согласился с блокировкой, о чём сообщил письменно. Хостер разблокировал сайт. Правообладатель подал в суд, разумеется на хостера, с иском о крупном взыскании. Суд вынес решение, что хостер не будет выплачивать взыскания, на основании того, что не получил официальных требований. Но при этом счёл требование правообладателя обоснованным в части нарушения авторских прав.
Хостер в этой ситуации, конечно, действовал строго по закону. В результате получил судебные издержки и судебный процесс. Клиент смог поработать лишние месяцы до завершения суда, потом скорее всего перенёс сайт к другому хостеру. То есть из трёх сторон виноват владелец сайта - а убытки у хостера. И это ещё хорошо, что хостер смог доказать суду, что активно пытался помочь в урегулировании спора и что ни ответчик (хостер), ни владелец сайта не получили прибыли от нарушения прав истца. А в другом случае, иск был бы удовлетворён полностью и хостер выплатил деньги по иску.
И теперь скажите честно, кто поступил бы на месте хостера так же? Да уверен, что и сам этот хостер в другой раз просто заблокировал - и всё.---------- Добавлено 10.04.2019 в 20:14 ----------
https://www.komtet.ru/kontakty/dokumenty/pro-abuzoustoichivyi-hosting
Пожалуйста. Кстати, неделю назад попросил юриста дополнить её конкретными статьями, по которым провайдер несёт ответственность и обязан осуществлять блокировку. Будет апдейт.
Так да не так. Правообладатель (или его представитель) может быть не прав, такое бывает. И клиенты далеко не все действительно занимаются пиратством или контрафактом. Но даже если владелец сайта чист, как ангел - но у правообладателя есть претензия, то хостер оказывается между молотом и наковальней. Хорошо, если правообладатель и владелец сайта договорятся, а если нет? Законодательство РФ вынуждает хостера следовать требованиям правообладателя, под угрозой суда и штрафа. То, что если хостер выиграет суд - сомнительно. Просто потому что суд не против владельца - у которого могут быть какие-то документы, а против хостера - у которого на момент суда не будет даже сайта на обслуживании.
Тот же Бренд монитор никогда не присылает хостеру - угрозу судебного преследования владельца сайта, они обращаются к ответственности хостера и грозят судом хостеру. Замечу, грозят обоснованно.
Кстати, мы всё-таки добились: последний месяц Бренд монитор абузы шлёт сразу с ЭЦП. Каждый раз мы даём на этом заработать юристу - который проверяет и отправляет официальный ответ, потому что мы обязаны это делать. И почти всегда результат - блокировка. Могу сразу сказать, что официальная абуза автоматически делает клиента виртуального хостинга нерентабельным, независимо от того - прав клиент или нет. Я не оправдываю тех хостеров, кто блокирует сразу при любой жалобе, но вопрос рентабельности и рисков отлично поясняет, почему часто хостеры блокируют, не требуя официальных заявлений. А сказать правообладателю "решения суда нет? до свидания!" российские хостеры не могут.
Эти вот особенности российского законодательства привели к тому, что наша компания оказалась в топе абузоустойчивых хостеров только за формальное отношение к исполнению закона и чёткое следование его букве. Что тоже стало для нас проблемой в некотором роде: в наш офис пришли два сотрудника ФСБ, выяснять, как это российский хостинг стал абузоустойчивым :) Мы даже статью про реалии абузоустойчивости в России написали после этого.
С другой стороны, недобросовестные клиенты отлично знают о "рисках" своего "бизнеса" - и просто таскают сайты кругами по хостерам, зачастую, довольствуясь тестовым периодом. В результате, юристы правообладателя и наши юристы - зарабатывают, сайт продолжает работать без особого ущерба для клиента - а крайним оказывается хостер.
Лично я - за права граждан. Но для начала я посоветую прочитать Статью 1253.1 ГК РФ. Особенности ответственности информационного посредника.
Разумеется, тут нужен разбор. И мы стараемся разбираться, проверяем сами, в сложных случаях привлекаем юриста, если есть сомнения - трактуем в пользу клиента. Несём убытки из-за недобросовестности Клиентов.
А теперь порассуждаем, представьте ситуацию.
Есть услуга хостинга, стоит она сто рублей в месяц. Первый месяц вообще бесплатно. Разместили на этой услуге сайт с кинофильмами, и приходит абуза от правообладателя, пока только по электронке.
С юридической точки зрения, хостер должен потребовать официальное заявление от правообладателя. Тогда и только тогда хостер, как информационный посредник, будет официально уведомлен. ОК, мы потребовали. Пришли официальные бумаги (на самом деле, мы требуем такие бумаги почти всегда, и часто их получаем). Мы передаём эту официальную бумагу юристу, юрист пишет официальный ответ и отправляет Почтой России да ещё с уведомлением. Напомню, что клиент ещё ни копейки не заплатил или заплатил сто рублей. При этом мы всё равно блокируем, почему? См.Статью 1253.1 ГК РФ.
Теперь предположим, что хостер встаёт в позу, и требует решения суда (как этого хотите вы). Тогда правообладатель подаст в суд. Но подаст в суд НА ХОСТЕРА - его достать намного проще, чем владельца сайта, который анонимизирован, и идти в суд вместо нашего юриста не собирается. Для клиента - эта бумажная волокита только на руку. А дальше просто, хостер - информационный посредник, был официально уведомлен - и хостеру прилетает штраф, плюс оплата судебных издержек. При этом, подчеркну, хостер или вообще не заработал ни копейки, или заработал 100 рублей - понёс большие убытки, а клиент просто ушёл в другую компанию.
Я даже больше скажу, ушлые правообладатели стали СРАЗУ подавать в суд на хостера (без предварительного официального уведомления) - у нас уже было несколько таких судов, в том числе с соответчиком CloudFlare. Да, штрафы нам не присуждали по таким судам, потому что правообладатель в таком случае требует только блокировки сайта. Но бумажки в эти суды мы регулярно отправляем и к юристу обращаемся - заметьте, за свой счёт. И эти издержки тоже несопоставимы с низкой стоимостью хостинга. При этом мы клиентов информируем о том, что подали в суд по поводу их сайта, но ещё ни разу ни один клиент не ответил: "ОК, я оплачу все судебные издержки и штрафы". Все клиенты просто дожидаются решения суда, блокировки - и уходят к другому хостеру, с которым история повторяется.
Так что делать хостеру? Вставать грудью на защиту граждан? Так что проблема - в текущем российском законодательстве. В моей личной идеальной вселенной сайт можно заблокировать ТОЛЬКО после суда, в котором одна из сторон - правообладатель (или прокуратура), а другая сторона - реальный владелец сайта (которого нашли). А в реальности, настоящего владельца сайта никто не ищет и судят "информационного посредника", то есть хостера.
UPD: Вот свежая история, у клиента в имени домена - "yandex", есть претензия Яндекса, нет решения суда. Требовать решения суда? Отправить юристов в Московский Городской Суд, чтобы доказывать, что домен нашего клиента не нарушает права Яндекса? И с 99.99% вероятностью проиграть? А Яндекс угрожает судом - нам, а не компании, которой принадлежит домен (которая не скрывается, но судиться с Яндексом не хочет).
С точки зрения безопасности вы, конечно, правы. Хотя и не припомню взломов через старые версии PHP. Но статистика развертывания сайтов показывает, что в основном размещают как раз "старые" сайты, которые не работают с PHP 7. Владельцы таких сайтов зачастую вообще понятия не имеют, что есть какие-то ещё "версии PHP". Их реакция: я перенес сайт, сайт не работает - виноват хостер. Многие просто молча уходят, столкнувшись с любой проблемой, благо первый месяц никаких денег платить не надо.
А те, кто размещают сайты на новых движках, которые требуют последних версий - отлично знают, что им нужна новая версия и как выбрать версию PHP в панели, благо сделать это несложно. На текущей дефолтной версии работает больше движков, чем на самой последней версии PHP. То есть устанавливая новейшую версию в качестве дефолтной - мы фактически увеличим число негатива и запросов в саппорт...
Ну и наконец, если кто-то ставит CMS из панели хостинга - то при установке проверяется используемая версия. Так что владельцы новейших CMS будут проинформированы заранее о необходимости выбора новейшей версии. Мне вот даже стало интересно, а много ли CMS не работают на PHP ниже 7.х...
Ну и наконец, опять же статистика запросов показывает, что последние версии выбирают редко, а пишут про это ещё реже. Вы действительно полагаете, что нам стоит поднять дефолтную версию - только потому что так "правильно" (и я согласен, что это правильно)?
Ну вот потому что большинство проектов не работают на последних версиях PHP и им достаточно 5.х - она и дефолтная. Но есть возможность выбора из довольно большого выбора версий, вплоть до последних.---------- Добавлено 02.04.2019 в 17:37 ----------
У нас были и валютные счета, и приём нескольких валют - был даже опыт приёма цифровой валюты. Но поскольку мы в российском правовом поле работаем - в какой-то момент это надоело бухгалтерии и юристам.
Поэтому да, все цены только в рублях и оплата только в рублях. Но - у нас есть клиенты и из ближнего зарубежья, и из дальнего. В основном они оплачивают PayPal со своих счетов или карт - а мы получаем уже рубли на расчётный счёт. И все довольны.---------- Добавлено 02.04.2019 в 17:43 ----------
С этим не поспоришь ;) Ещё раз спасибо за внимание.
Но вдруг понадобятся наши услуги: SSL-сертификаты, домены или (чем черт не шутит) хостинг - в индивидуальном порядке сделаем по себестоимости )
Да это так себе проблема. ) Можно ещё раз зарегистрироваться или добавим пару месяцев (нужен номер биллинг-аккаунта), можно в личку или на iv@komtet.ru
КОМТЕТ справедливо упрекнули за несовременный дизайн и отсутствие мобильной версии. Обновление мы уже на тот момент готовили - но обновить дизайн для всех служб, которые из себя представляют тот ещё зоопарк технологий - не так быстро.
Дизайн заменили, мобильная версия работает для большинства сервисов. Теперь дело за картинками на главной и в основных разделах сайта. )---------- Добавлено 17.03.2019 в 14:17 ----------
Мы и не хотим совсем отключить тикетницу в ISP. В планах скрестить встроенную тиикетницу с OTRS, тогда не нужна будет отдельная регистрация в OTRS.---------- Добавлено 17.03.2019 в 14:19 ----------
Там аккаунт реселлера высылается отдельно, если на заказанном тарифе он доступен. Но путаница есть с аккаунтами реселлер/нереселлер, с этим не поспоришь. Будем думать, как проинформировать о возможностях реселлера на старших тарифах, чтобы не путать клиентов.---------- Добавлено 17.03.2019 в 14:22 ----------
К СУБД изначально в панели прописано, с каких IP открыт внешний доступ, и это только IP веб-сервера. Эта настройка видна. Можно заморочится, отключить внешний доступ пообще - но зачем? Проще контролировать те IP, с которых есть внешний доступ. Для серверов баз данных, поскольку они все отдельно от виртуального хостинга стоят - любой доступ будет внешним.
Прокомментирую, как хостер, ибо различные представители правообладателей нас изрядно напрягают - поскольку российское законодательство легко позволяет напрячь хостера, как информационного посредника и наказать за соучастие.
Конкретно вот эти жалобщики никогда не присылают официальные бумажные документы почтой и не заверяют сообщения электропочтой ЭЦП (что равнозначно бумажным документам). Они даже почти никогда не отвечают на наши письма. Однако, это совершенно не значит, что их требования всегда неправомерны. Чаще всего хостеры прислушиваются к требованиям, потому что риск получить судебный иск велик, риск его проиграть - тоже. При этом судебные издержки будут несоизмеримо выше стоимости любой услуги - не говоря про возможный штраф.
Если клиент использует CDN типа CloudFlare, то абуза прилетит сначала от CDN, потом от правообладателя - потому что CloudFlare спалит реальный адрес сайта, то есть так себе защита.
Вообще ситуация с абузами такова, что мы, конечно, требуем предоставить официальные документы и не блокируем (закон нам позволяет игнорировать анонимки по электропочте), но вот правообладателям тот же закон позволяет подать на нас в суд и вчинить не только штраф, но и оплату расходов по иску. И иногда это происходит. В лучшем случае, решение суда блокирует домен и он оказывается в реестре. В худшем случае, суд блокирует и IP - такое тоже бывает. А в самом худшем случае, прилетает штраф и оплата расходов. Для этого совершенно не обязательно появляться на суде. Поэтому большинство российских (и не только) хостеров при абузе и блокируют.
Так что если есть проблемы с B-M в частности - лучше сразу искать зарубежный абузоустойчивый хостинг. С юрлицом в РФ таких не найти. Но и в этом случае, если правообладатель подаст в суд, то он 100% выиграет суд (а мы не раз получали решения судов, иногда с соответчиком в виде CDN-сервиса) - и домен будет в Реестре, а значит не будет открываться в РФ. То есть даже зарубежный абузоустойчивый хостинг не поможет. А убрать из реестра - надо связываться с РКН. А они не то чтобы совсем не отвечают, но и решение суда так просто не отменишь и даже заблокированный IP - из реестра удалить не так просто и быстро.
Я даже взял таймаут, и не сразу смог ответить, так много информации. Спасибо )
Собственно, вход в биллинг один https://bill.komtet.ru/, недавно биллинг заменили полностью, так что старые ссылки могли остаться, но и они все ведут на bill.komtet.ru.
Вход доступен, конечно, и через Витрину. Как вариант. Но и он работает. Собственно говоря Витрина это не биллинг, она только для быстрого заказа услуг, прежде всего тестовых - чтобы не приходилось заполнять кучу полей.
Тикетница в биллинге есть своя и к сожалению, её не отключить. Тикетница не слишком удобная, поэтому мы продолжаем пользоваться OTRS: https://help.komtet.ru/. Но пока вопрос не решён, можно писать и через родную тикетницу билинга, и через "нормальную". Либо просто на support@komtet.ru или форму обратной связи - что то же самое. Всё в результате оказывается в OTRS.
С реселлерами. Фича удобная, я считаю. Особенно для тех, кто сопровождает чужие сайты. Собственно похожая опция была у нас и когда была PPA (Plesk), и есть сейчас. Используют чтобы развести по независимым услугам, что понятно и из названия. Поэтому там +1 уровень пользователей. На младших тарифах, кстати, реселлерский уровень тоже есть, просто мы его скрываем. Подумаю, может ещё как дополнить статьи про реселлеров и вообще раздел.
Ну и относительно nginx+PHP-FPM (я поднял в тикетнице вашу переписку и посмотрел) к сожалению, технической возможности править конфиги nginx - нет. И да, это ограничения панели. Но саппорт не отказался вносить изменения, опять же остаётся режим FastCGI (Apache) + nginx где такой проблемы нет. Для чего и кому нужен nginx+PHP-FPM - мне и самому интересно, я запросил статистику - кто у нас и для чего его использует. Будет инфа - поделюсь. Что-то подсказывает, что мало кто переходит на nginx+PHP-FPM )---------- Добавлено 27.02.2019 в 13:50 ----------
Внешний доступ к серверу СУБД, по умолчанию, действительно включен. Но только с IP-адреса веб-сервера, так что отключать его нет смысла. И можно добавить ещё IP-адреса, с которых данный пользователь может получить доступ к СУБД. Частенько разработчики запрашивают внешний доступ с базе, это удобно. Как этим пользоваться описано в статье. Это удобнее, чем было у нас раньше реализовано в старой панели. Как удобнее я даже не знаю.
