- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Как удалить плохие SEO-ссылки и очистить ссылочную массу сайта
Применяем отклонение ссылок
Сервис Rookee
- обновление ОС?
- "Только перенос на сервер со свежей ОС",
Зачем перенос? Debian можно обновить и без переноса. ТП не знает этого?
Если клиент хочет уровень "всё включено" по цене "без питания".. и "хорошо, готов доплатить за завтрак, но обеспечьте шведский стол на обед и ужин", то, вполне возможно, что пора расходиться.. Или присмотреться повнимательнее..
Выше baddl написал, что готов оплатить услуги, но ему так и написали план работ и сумму.
Складывается ощущение, что поддержке делать просто ничего не хочется, поэтому отвечают в стиле "это будет долго, дорого, лучше сами делайте или к кому другому обратитесь". И, видимо, обратиться к сторонним сисадминам в таком случае будет лучшим выходом из положения.
...Складывается ощущение, что поддержке делать просто ничего не хочется...
Такое впечатление сложилось сразу же, как только увидел первый ответ "У нас нет подробной информации по поводу поддержки данного модуля".
К сожалению, по мере общения стало очевидно - это не проблема конкретного сотрудника. Скорее всего, это системная ошибка того, кто выстраивал логику работы техподдержки. Цели такого построения понятны: разбить делегирование как можно мельче, плюс отсечь мелкие и нежелательные запросы. К сожалению, около года назад что-то пошло не так, и границы "нежелательного" расширились. Результат: 4 нерешённых тикета за год (при этом, я обращаюсь только в случае непонимания ситуации или опасения её ухудшить, и готов оплатить любую работу, которую не могу сделать сам).
Сейчас общение с ТП по данному запросу полностью закончено. Все вопросы обсуждены, цены и список работ выужены (это самый точный термин) - объём, сумму и сроки я понял.
Не буду портить ситуацию личным мнением. Просто резюмирую:
Первоначальный запрос: "Imagick не поддерживает работу с форматом Webp. Просьба помочь с вопросом."
Конечное предложение от ТП: "Заказываете дополнительный VPS, ставите современную ОС, перенос сайтов = 100 р/сайт, про объём и цену настройки сервера - после переноса."
Время общения с ТП: 90 часов.
Пожелание представителям Айхора: всё-таки проанализируйте тикет. Только переставьте себя на место клиента.
(Старался писать без какого-либо негатива.)
Все вопросы обсуждены, цены и список работ выужены (это самый точный термин) - объём, сумму и сроки я понял.
Сложность в том, что все хотят услышать конечную стоимость.. причём низкую..
"Сколько стоит сайт перенести"... "Сколько стоит машину отремонтировать"? "Какой/Какую"?
"Обычный.. на wordpress" (Обычная, на третьем этаже)
При том, что, строго говоря... поддержка может перенести файлы и базу.. и даже версии ПО настроить (если панелька поддерживает).. и.. возможно, даже, конфиги поправить.. и, теоретически всё должно работать..
А разбираться, кто что и куда засунул, что оно при "обычном-стандартном" переносе не работает.. (опять же, строго говоря), по идее не входит в задачи "техподдержки" хостинга..
Теоретически, сроки на "перекинуть дамп и файлы" сводятся к скорости генерации и архивации и пропускной способности канала..
Практически - может потребоваться недюжинное терпение, чтоб запустить старый сайт с парой хитрых функций, с использованием пары-тройки недокументированных хитрулечек и кучи deprecated-ов (как в самом сайте, так и в библиотеках-расширениях).. на новом месте (ОС+ПО)
Логика в решении именно с целью борьбы есть, однако, при таком раскладе нужно городить много DNS-серверов (либо хостить DNS на сервере хостинга, что на сёрче считают школохостерством), при переносе сайтов между серверами нужно, либо переносить вместе с ними NS, либо просить клиента менять NS, что телодвижения и задержки.
Когда NS едины для всех услуг, можно перемещать клиента в рамках своей инфраструктуры без каких-либо телодвижений со стороны клиента.
Всегда можно найти простое и дешевое решение, было бы желание. Когда желания нет, находится объяснение, почему это нецелесообразно. Я это прекрасно понимаю, у самого такое периодически бывает.
Необязательно делать сложную инфраструктуру.
domain1.com
ns23.megahoster.com 192.168.0.1
ns25.megahoster.com 192.168.0.2
domain2.ru
ns26.megahoster.com 192.168.0.1
ns28.megahoster.com 192.168.0.2
Когда у domain1.com идет набор днс для domain2.ru, он не отвечает. Хотя хостятся днс на тех же виртуалках, т.е. на тех же айпи. У кого проблемы с настройками такой системы, могу помочь. Генерировать можно и не пару нс, а две пары (т.е. четыре нс). Возможно это может помочь и в других вопросах (особенно в контексте абуз, можно быстрее установить проблемную группу клиентов).
baddl, Внимательно изучили тикет и проанализировали его ещё раз. Мы понимаем причину вашего недовольства, мысль, которую вы хотели до нас донести тоже ясна. Услуги, которые вам понадобились, не совсем входят в профиль работы технической поддержки, задача в принципе была не самая типичная и требовала время на рассмотрение. Нужно было понять, что могли предложить наши сотрудники для её решения, даже несмотря на её рассмотрение в рамках платного администрирования. В прейскуранте услуг по платному администрированию в принципе отсутствует такая услуга, как настройка Imagick, однако есть возможность выполнения работ по ТЗ, о чём первый специалист вам и ответил.
Помимо этого, сотрудники технической поддержки всегда предупреждают о возможных последствиях, которые могут возникнуть после проведения каких-либо действий. Мы считаем, что это правильно, так как по нашему мнению, прежде чем дать своё согласие на проведение каких-либо работ, клиенту необходимо быть в курсе того, какие изменения могут произойти после их осуществления.
Однако, мы уловили вашу обратную связь, подумаем над решением, которое поможет ускорить процесс обработки подобных вопросов и ситуаций. Внесём в регламент поправки, которые помогут сделать обработку таких запросов более оперативной. Спасибо.
К сожалению, около года назад что-то пошло не так, и границы "нежелательного" расширились. Результат: 4 нерешённых тикета за год (при этом, я обращаюсь только в случае непонимания ситуации или опасения её ухудшить, и готов оплатить любую работу, которую не могу сделать сам).
Примерно около года назад в ветке Айхора объявили о смене начальника техподдержки и реорганизации отдела. Не знаю, чем именно не угодил прежний начальник и в чем заключалась реорганизация, но, похоже, на пользу отделу и компании это не пошло.
MPZ, что-то Вы очень часто в этой ветке появляетесь, по любому поводу и без... не Вы ли тот самый, неугодивший чем-то экс-начальник техподдержки?
MPZ, что-то Вы очень часто в этой ветке появляетесь, по любому поводу и без... не Вы ли тот самый, неугодивший чем-то экс-начальник техподдержки?
Нет. :) Я появляюсь там, где вижу что-то интересное для себя.
Начальника отдела сменили около года назад, появляться экс-начальнику здесь именно сейчас было бы несколько странно, мне кажется.
А вы, смотрю, в принципе только в этой ветке отписываетесь. Сотрудник компании, полагаю? Второй аккаунт нынешнего начальника? 🤣
Стало известно о критической уязвимости PHP-FPM (CVE-2019-11043), которая позволяет удалённо выполнить вредоносный код на сервере.
Уже доступны корректирующие релизы PHP 7.3.11, 7.1.33 и 7.2.24, в которых устранена данная уязвимость. Найти их можно по ссылке: https://www.php.net/archive/2019.php
По информации opennet.ru, атака возможна в конфигурациях nginx, в которых проброс в PHP-FPM осуществляется c разделением частей URL при помощи "fastcgi_split_path_info" и определением переменной окружения PATH_INFO, но без предварительной проверки существования файла директивой "try_files $fastcgi_script_name" или конструкцией "if (!-f $document_root$fastcgi_script_name)".
Чтобы проследить за ходом устранения проблемы в дистрибутивах, следует воспользоваться следующими страницами:
Debian: https://security-tracker.debian.org/tracker/CVE-2019-11043
RHEL: https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2019-11043
Ubuntu: https://people.canonical.com/~ubuntu-security/cve/2019/CVE-2019-11043.html
SUSE/OpenSUSE: https://bugzilla.suse.com/show_bug.cgi?id=CVE-2019-11043
FreeBSD: http://www.vuxml.org/freebsd/
Arch: https://security.archlinux.org/CVE-2019-11043
Fedora: https://bodhi.fedoraproject.org/updates/FEDORA-2019-7bb07c3b02
Добрый день. Мне кажется у вас кто-то или что-то нехорошее завелось:
Странные "бэки" появились у меня.