Есть выделенный сервер на CentOS 7 на котором хостится муниципальный сайт на битриксе.
Проблема в том, что сайт (в основном, по ночам) становится не доступен и судя по логам
Nginx выдаёт ошибку 403. "Ложится" он на время от 5 до 50 минут и потом сам "поднимается".
Доступ для пользователей к директории с битрексом есть на чтение и запись. htaccess
(на сколько я могу судить) стандартный битрексовский. Наименование файлов корректное.
Думал, что это может быть из-за бэкапов, но "ложится" сайт по времени рандомно. Подскажите,
пожалуйста, что может быть?
Ответы
Ответ 1
Требуется для начала исследовать кто выдает ошибку 403: Nginx/Apache или PHP-код.
Найти это можно в логах nginx/apache и по заголовкам ответа (X-Powered-By).
Далее требуется разбиратся с логами конкретного сервера nginx/apache (и искать в
логе ошибок причину ошибки 403) либо при выдаче этого кодом php - разбиратся в нём
Ответ 2
Нашёл причину (точнее, помог коллега). Оказалось, всё было в банальном фишинге сайта
(использовали rk.php для перенаправления на свои сайты). По этой причине, сервер временно
блокировал балансировщик пересылающий эти запросы серверу. Решается это всё в настройках
Битрикса. Нужно зайти в интерфейс Битрикса, в раздел меню "Проактивная защита", дальше
в "Защита редиректов" и включить защиту редиректов. Битрикс будет подписывать ссылки
через rk.php.
Есть два понятия:
сниппет — кусок кода, который можно использовать повторно,
система контроля версий — система, используемая для того, чтобы несколько программистов
работали над одним проектом и использовали один репозиторий.
Вопрос в следующем. Я пробовал пользоваться Github, но это несколько затратно ввиду
моих нужд. Нужно, чтобы на некоем сайте можно было начать проект, была примитивная
возможность создавать папки, сливать туда файлы с кодом, и этот же код, просматривать
онлайн. Сливать именно через браузер, а не через систему контроля версий (часто работаю
на разных компьютерах, а устанавливать и настраивать git, желания нет).
Сниппеты не катят, потому что это не файлы. А искать, если проект состоит более чем
из одного файлы радости не доставляет. Плюс бывают файлы с моделями, а их таким образом
уже не зальешь.
Заранее спасибо за дельные советы и ссылки.
Ответы
Ответ 1
Обычно в таких ситуациях (когда система контроля версий - слишком тяжеловесно) используют
Dropbox.
UPD
Несколько извращенный вариант, но просмотр кода он-лайн есть, да еще и с примочками:
CodeRemarks
Ответ 2
Может быть вам просто подойдет онлайн-хранилище файлов как dropbox,или нужно что-то
более специфичное?
Ответ 3
Мне нравится система контроля версий Bazaar. Код сливаю на launchpad, где можно посмотреть
код онлайн. Система является распределенной, что является удобной, когда пишу код на
разных компьютерах, в разных операционных системах.
http://ru.wikipedia.org/wiki/Bazaar
Ответ 4
OwnCloud похоже то, что требуется. Можно поставить свой сервер, можно купить хостинг
с этим сервисом.
Добавлено.
Если все-таки выбирать из всех возможных вариантов, в том числе и с контролем версий,
то можно начать отсюда: сравнение хостингов
Доброго времени суток. Сегодня захожу на свой некий сайт и вижу следующее Данный
домен зарегистрирован в интересах клиента.
Зашел в билинг панель хостера и вижу что заказанного мною хостинга физически не существует.
Пропали труды 3-х месячной работы над проектом.
На почте хранится куча сообщений о заказе услуги, ее продлению и т.п.
Кто сталкивался с подобным ранее? Какие мне принимать меры по произошедшему и т.д.
Хочу услышать ваши советы и прочее.
UPD
Администраторы уже занимаются решением данной проблемы. В ближайшее время работа
аккаунта будет восстановлена.
Приносим извинения за доставленные неудобства.
Жду)
Ответы
Ответ 1
ну если есть доказательства на почте, смело пиши им и звони!
Если пойдут на попятную, смело подавай в суд, распечатывай материалы с почты - тогда
они запоют другую песню.
//upd
Сначала позвони в саппорт, если в саппорте тебя мягко говоря пошлют, проси старшего
по саппорту, если и он такой же тугой, тогда если хостер в твоем городе смело едь к ним!
Приедишь к ним, в руках у тебя уже должна быть бумага в 2х экземплярах о том что
случилось и что ты хочешь в этом разобраться! один они берут себе, на втором ставят
приходный номер и печать, и ФИО того кто принял заявление. в течении времени они обязаны
ответить тебе.
Можешь распечатать в свое доказательство письма с почты, причем в заголовках писем
есть от кого отправлено вплоть до IP.
Думаю они быстро решат проблему, иначе 1 отзыв в нете может ой как пагубно отразиться
на всем хостере!
@Palmervan если есть доказательства на почте, смело разговаривай с ними на тон выше,
чем обычно. Не навязывай им то что ты прав, а говори это! Если они не тупые пойдут
на встречу и все сделают, если тупые -суд и они станут еще тупее.
//upd
физически удалить все равно его проблематично в плане бекапов. т.е. тут дело в чем,
если пропали данные только у тебя - то дело пахнет керосином, если у 100 клиентов такое
же то тут беда вселенского масштаба - но тоже подпадает под нарушение со стороны хостера.
А ежели только твой аккаунт - тогда вопрос встанет иначе что они руками искоренили
акк + всю инфу и дампы - а это еще +1 в твою карму и выигрыш дела на суде.
Ответ 2
Надо садиться на уши хостеру и ездить ему же по мозгам. Скорее всего, что-то слетело
у них. И, если повезло, найдутся бэкапы и всё восстановят.
Добрый день, коллеги!
Есть вопрос, какие есть способы облегчения жизни веб разработчика в редактировании
закаченного на хостинг сайта на cms. Например нужно доработать новый функционал, с
изменением многих структур, и записей в базе данных?
у меня два варианта (оба отстойные)
Залить весь сайт и базу на комп, расшарить их на локальной машине, после изменений
заливать обратно, минусы - очень гемморно, большие объемы передавать приходится, ну
и пока сайт на локальной доработке, его оригинал могут пополнить материалами, которые
после закачки новой версии похерятся.
Далее скачивать по одному файлу изменять заливать обратно, очень муторно отслеживать
результат, изменил пару строк, перезаписываешь файл, и так до бесконечности, ну и плюс
мега много действий для простой задачи.
В общем, матерые веб девелоперы, как осуществлять сие действие по всем правилам этикета
=)
Ответы
Ответ 1
Сделать копию сайта и базы в подпапке на хостинге, и дорабатывать ее.
Когда все готово, глубокой ночью, перенести из старой базы измененный/добавленный
за это время контент; проверить все еще раз, и поменять "сайты" местами. Если что-то
пойдёт не так, ещё можно будет откатиться назад относительно безболезнено.
Если же совсем всё сложно, надо объявить комендантский час, и запретить на какое-то
время юзерам что-то менять в базе — read only. Заранее спланировать, сколько примерно
времени понадобится, удвоить его, и торжественно объявить всем: такого-то числа с 8
до 16 отключаем горячую воду!
Ответ 2
какие есть способы облегчения жизни веб разработчика
Работать в той же среде, что и хостинг. То есть - не в Windows (если, конечно, хостинг
не виндовый, но люди, сознательно идущие на это, подобных вопросов не задают).
Ответ 3
Код сайта можно редактировать через различные IDE (типа NetBeans или Eclipse). Создав
специальный проект подключенный к вашему сайту. Любое изменение, которые вы сделаете
в среде разработки будет сохранено на сайте. Среды разработки также поддерживают синхронизацию
с системами контроля версий git и svn. А с базой можно работать со стандартного клиента,
который идет с субд MySql или oracle, подключившись к удаленной базе.
Сижу на хостинге, и у некоторых пользователей очень долгая загрузка сайта.
Разбирались, и нашли почему такая проблема, но не нашли решения.
На сайт подключается стиль стандартным способом:
В стиле всего 79 строчек, но самую большую нагрузку в стилемов файле беру изображения:
background: url(../images/bg.jpg);
И вот каждая картинка грузит около 3-5 секунд (весом 900кб).
Не понимаем, с чем связана эта проблема, у 95% пользователей все окей, а у остальных
5% - такая вот беда...
При прямом открытии картинки по URL, эту картинку грузит все равно те же 5 секунд,
а остальные - шустро (200мс в среднем).
В какую сторону стоит копать в такой ситуации?
Ответы
Ответ 1
Я бы посоветовал вам оптимизировать весь статический контент на сайте.
Сжатие графики
В вашем случае кроме сжатия стилей и скриптов посоветую сжимать и графику. К примеру,
картинки можно легко сжать без потери качества только за счет удаление exif-данных.
На реальном сайте можно сократить размер картинок в среднем на 70%, что на современном
сайте равняется примерно 4 МБ. Пример на gulp:
var
gulp = require('gulp'),
imagemin = require('gulp-imagemin'),
imageminJR = require('imagemin-jpeg-recompress'),
imageminSvgo = require('imagemin-svgo');
// Optimizing images
gulp.task('imagemin', function() {
gulp.src('./img/**/*')
.pipe(imagemin([
imageminJR({
method: 'ms-ssim'
}),
imageminSvgo({
plugins: [
{removeViewBox: false}
]
})
]))
.pipe(gulp.dest('./public/img/'))
});
А для браузеров, которые понимают легковесный формат webp (формат разработан Google),
можно сделать еще такой вариант изображений:
var
gulp = require('gulp'),
webp = require('gulp-webp');
// Generate Webp
gulp.task('webp', function() {
gulp.src('./img/**/*')
.pipe(webp())
.pipe(gulp.dest('./public/img/'))
});
Оптимизация скриптов
Сперва объедините все скрипты в один файл и минифицируйте их. Это помет сократить
количество HTTP-запросов и размер файлов:
var
gulp = require('gulp'),
concat = require('gulp-concat'),
uglify = require('gulp-uglify');
// Concat JS
gulp.task('js', function(){
gulp.src([
'./js/jquery.js',
'./js/wow.js',
'./js/menu.js',
'./js/scrollspy.js',
'./js/main.js',
'./js/temp/contact.bundled.js',
'./js/owl.carousel.js'
])
.pipe(concat('script.js'))
.pipe(uglify())
.pipe(gulp.dest('./public/js/'))
});
Оптимизация стилей
Кроме обычной минификации стилей можно использовать и продвинутую - объединять дубликаты
классов и @media. Пример на gulp из моего [web-starter-kit][1]:
var
gulp = require('gulp'),
stylus = require('gulp-stylus'),
// Минифицирует CSS, объединяет классы. Не ломает CSS, в отличие от cssnano,
который, к примеру, может неправильно выставлять z-index
csso = require('gulp-csso'),
// Объединяет все @media
cmq = require('gulp-combine-mq'),
// Сокращает CSS-селекторы
gs = require('gulp-selectors'),
// Проставляет вендорные префиксы
autoprefixer = require('gulp-autoprefixer'),
livereload = require('gulp-livereload'),
nib = require('nib');
// Compiling Stylus in CSS
gulp.task('css', function() {
gulp.src('./styl/*.styl')
.pipe(stylus({
use: nib()
}))
.pipe(cmq())
.pipe(csso())
.pipe(autoprefixer('last 3 versions'))
.pipe(gulp.dest('./public/css/'))
});
А если совсем делать нечего, то можно еще и селекторы сократить:
// Minify selectors
gulp.task('gs', function() {
var ignores = {
classes: ['active', 'menu', 'nav', 'slide', 'error', 'form-control',
'loader', 'showLoader', 'fadeLoader', 'webp', 'wow', 'owl-*', 'i-*'],
ids: '*'
};
gulp.src(['./public/**/*.css', './public/**/*.html'])
.pipe(gs.run({}, ignores))
.pipe(gulp.dest('./public/'))
});
Кстати, наверняка у вас есть классы, добавляющиеся через JS, поэтому предварительно
стоит все такие классы вынести в переменную ignores.
Кеширование статики на стороне пользователя
Также бы посоветовал кешировать скрипты и стили на стороне пользователя, чтобы исключить
их повторную загрузку, если они не изменились:
Header set Cache-Control "max-age=2592000"
И включить gzip сжатие на сервере:
# сжатие text, html, javascript, css, xml:
AddOutputFilterByType DEFLATE text/html text/plain text/xml application/xml application/xhtml+xml
text/css text/javascript application/javascript application/x-javascript
Ответ 2
Сами ответили на свой же вопрос. У одних хорошо, у других плохо. Зависит от скорости
приёма клиентов, и от скорости отдачи веб-сервера. Чем дальше от сервера, тем хуже
прием. Чем меньше скорость приёма, тем медленнее скорость загрузки.
Принцип подгрузки больших элементов прост - сначала загружайте всё то, что сформирует
страницу предельно быстро - основные стили, основной каркас, минимальные иконки. А
вот большие уже элементы, к примеру Ваш фон, подгружайте отдельным стилем, к примеру
асинхронно (jQuery), тогда и клиент быстрее увидит страницу, а там уже и картинки подгрузятся.
Несмотря на свою деятельность в веб-разработке, пока ещё не достиг глубокого понимания
сущности интернета и этот вопрос - один из шагов на пути к осмыслению.
В Википедии, в статье "Интернет" среди юридических аспектов и общих свойств интернета
приведено:
У Интернета нет собственника, так как он является совокупностью сетей,
которые имеют различную географическую принадлежность.
Если это прочитает человек, не имевший ранее дело с интернетом, он наверняка может
прийти в выводу, что всё, что нужно для опубликования своего сайта в интернет - подключённый
к интернету компьютер и никаких хостинговых компаний и регистраторов доменных имён.
Насколько я уже знаю, для того, чтобы начать "транслировать" свой сайт в интернет,
нужно открыть 80-ый порт (например, с помощью веб-сервера Apache, который является
ПО). Конечно, безопасность персонального для компьютера такой трансляции - уже другой
вопрос. Но что представляет собой технически покупка доменного имени? Почему мы не
можем присовить произвольное доменное имя своему сайту хотя бы в пределах некоторых
доменных зон и транслировать его со своего компьютера под этим доменным именем? Выходит,
у интернета всё-таки есть собственник, который наделяет правом регистраторов доменов
продавать эти доменные имена?
Ответы
Ответ 1
Собственника у Интернета нет, но есть координатор. Исторически сложилось так, что
координатором является ICANN.
Почему же мы не можем просто так взять произвольное имя? Потому что это имя должно
быть известно всем и однозначно разрешаться в IP-адрес компьютера. Для этого служит
DNS. И именно за внесение записи в эту глобальную для всего мира таблицу соответствия
имён и IP-адресов вы и платите при покупке доменного имени.
Можно ли не платить? Можно. Например, можно вписать соответствие имени и IP в локальный
файл hosts. Но тогда сайт будет доступен только с тех компьютеров, где мы этот файл
изменили. Можно поднять свой собственный DNS-сервер, на котором указать наше имя и
использовать этот сервер для всех компьютеров, которым нужен наш сайт. Но вряд ли произвольный
пользователь в Сети согласится на это. К тому же, если каждый сайт сделает такой сервер,
то для клиента будет абсолютно неудобно этот адрес DNS-сервера постоянно переписывать.
(Но это хорошее решение для внутренних сетей организаций.) Поэтому большинство предпочитает
заплатить и не мучиться.
Есть ещё один способ получить имя бесплатно. Надо найти того, кто уже купил имя второго
уровня (или более низкого), например, example.org, договориться с ним и попросить внести
запись более низкого уровня, например, vasya.example.org. Это можно сделать, поскольку
владелец домена может прописывать любые записи для всех поддоменов.
Ответ 2
Технически, для сайта и правда достаточно подключенного к интернету компьютера с
открытым портом. Вот только на такой сайт посетителям придется ходить по IP-адресу.
А IP-адрес, вообще говоря, является собственностью провайдера и может быть изменен.
В этом случае придется как-то рассказывать всем посетителям свой новый адрес.
Замечание. Вообще говоря, существует возможность приобрести себе постоянный IP-адрес
- но это доступно только юридическим лицам и будет стоить дороже доменного имени.
Один из способов подобного "рассказа" - это DNS. Служба, которая преобразует те самые
доменные имена в IP-адреса. Право создавать домены второго уровня имеют регистраторы.
Вот им-то и надо платить за домен.
После покупки доменное имя становится вашим - пока вы за него платите. В частности,
это означает что никто без вашего ведома не может отобрать его у вас (кроме как через
суд в некоторых случаях).
Владея доменов второго уровня вы можете создавать любое число доменов третьего и
ниже уровней бесплатно. Иногда для этого надо поднимать свой DNS-сервер и открывать
53й порт, иногда не надо (зависит от регистратора).
Существуют также сервисы, раздающие бесплатные доменные имена третьего уровня. Но,
вообще говоря, вашими такие доменные имена также не являются.
Технически покупка доменного имени заключается в том, что вы платите регистратору
за то, что он внесет запись о соответствии некоторого имени вашему IP-адресу в некоторый
общий список.
Несмотря на свою деятельность в веб-разработке, пока ещё не достиг глубокого понимания
сущности интернета и этот вопрос - один из шагов на пути к осмыслению.
В Википедии, в статье "Интернет" среди юридических аспектов и общих свойств интернета
приведено:
У Интернета нет собственника, так как он является совокупностью сетей,
которые имеют различную географическую принадлежность.
Если это прочитает человек, не имевший ранее дело с интернетом, он наверняка может
прийти в выводу, что всё, что нужно для опубликования своего сайта в интернет - подключённый
к интернету компьютер и никаких хостинговых компаний и регистраторов доменных имён.
Насколько я уже знаю, для того, чтобы начать "транслировать" свой сайт в интернет,
нужно открыть 80-ый порт (например, с помощью веб-сервера Apache, который является
ПО). Конечно, безопасность персонального для компьютера такой трансляции - уже другой
вопрос. Но что представляет собой технически покупка доменного имени? Почему мы не
можем присовить произвольное доменное имя своему сайту хотя бы в пределах некоторых
доменных зон и транслировать его со своего компьютера под этим доменным именем? Выходит,
у интернета всё-таки есть собственник, который наделяет правом регистраторов доменов
продавать эти доменные имена?
Ответы
Ответ 1
Собственника у Интернета нет, но есть координатор. Исторически сложилось так, что
координатором является ICANN.
Почему же мы не можем просто так взять произвольное имя? Потому что это имя должно
быть известно всем и однозначно разрешаться в IP-адрес компьютера. Для этого служит
DNS. И именно за внесение записи в эту глобальную для всего мира таблицу соответствия
имён и IP-адресов вы и платите при покупке доменного имени.
Можно ли не платить? Можно. Например, можно вписать соответствие имени и IP в локальный
файл hosts. Но тогда сайт будет доступен только с тех компьютеров, где мы этот файл
изменили. Можно поднять свой собственный DNS-сервер, на котором указать наше имя и
использовать этот сервер для всех компьютеров, которым нужен наш сайт. Но вряд ли произвольный
пользователь в Сети согласится на это. К тому же, если каждый сайт сделает такой сервер,
то для клиента будет абсолютно неудобно этот адрес DNS-сервера постоянно переписывать.
(Но это хорошее решение для внутренних сетей организаций.) Поэтому большинство предпочитает
заплатить и не мучиться.
Есть ещё один способ получить имя бесплатно. Надо найти того, кто уже купил имя второго
уровня (или более низкого), например, example.org, договориться с ним и попросить внести
запись более низкого уровня, например, vasya.example.org. Это можно сделать, поскольку
владелец домена может прописывать любые записи для всех поддоменов.
Ответ 2
Технически, для сайта и правда достаточно подключенного к интернету компьютера с
открытым портом. Вот только на такой сайт посетителям придется ходить по IP-адресу.
А IP-адрес, вообще говоря, является собственностью провайдера и может быть изменен.
В этом случае придется как-то рассказывать всем посетителям свой новый адрес.
Замечание. Вообще говоря, существует возможность приобрести себе постоянный IP-адрес
- но это доступно только юридическим лицам и будет стоить дороже доменного имени.
Один из способов подобного "рассказа" - это DNS. Служба, которая преобразует те самые
доменные имена в IP-адреса. Право создавать домены второго уровня имеют регистраторы.
Вот им-то и надо платить за домен.
После покупки доменное имя становится вашим - пока вы за него платите. В частности,
это означает что никто без вашего ведома не может отобрать его у вас (кроме как через
суд в некоторых случаях).
Владея доменов второго уровня вы можете создавать любое число доменов третьего и
ниже уровней бесплатно. Иногда для этого надо поднимать свой DNS-сервер и открывать
53й порт, иногда не надо (зависит от регистратора).
Существуют также сервисы, раздающие бесплатные доменные имена третьего уровня. Но,
вообще говоря, вашими такие доменные имена также не являются.
Технически покупка доменного имени заключается в том, что вы платите регистратору
за то, что он внесет запись о соответствии некоторого имени вашему IP-адресу в некоторый
общий список.
Не могу найти хорошего хостинга, тот дорогой, а тот не подходит. Решил рискнуть поставить
на компьютер сервер, не могли бы вы написать плюсы и минусы этой затеи.
Ответы
Ответ 1
Плюсы:
Ты сам себе хозяин.
Много места для твоих проектов.
Минусы:
Постоянный шум компьютера.
Расходы на электричество.
Убиваешь свое железо.
Очень затратно.
Нужно постоянно мониторить, обслуживать сервер.
Постоянный онлайн, нужны средства на оплату трафика (если он не безлимитный)
Я бы не советовал заниматься данным мазохизмом, не пожалей пару баксов и возьми себе
нормальный хостинг, меньше геморроя будет. Я бы посоветовал jino.ru. В любом случае
это обойдется тебе дешевле, чем свой сервер. И я сомневаюсь что ты будешь использовать
всю мощь своего сервера.
Ответ 2
Плюсы имеются при выполнении двух условий:
если есть ненужный компьютер,
если есть бесплатный быстрый интернет.
Минусы:
никакой поддержки (владелец уехал в отпуск - сервер упал),
никакой надежности (отключили электричество в подъезде, сервер упал),
никакой скорости (обычная домовая сеть),
это не так уж и дешево (посчитайте, сколько стоит электричество и трафик).
Для более-менее серьезных проектов домашний сервер неприемлим из-за вышеуказанных
минусов. Хороших хостингов, вообще говоря, много.
Ответ 3
Во всяком случае, домашний сервер - это замечательный способ стать хорошим сисадмином.
Ответ 4
Если не подходят хостинги, так можно же виртуальный сервер арендовать, если у буржуйской
компании, то это не сильно дорого. Я думаю дешевле обойдётся, чем именно свой домашний
сервер.
Всем привет!
У меня проблемка. Перерыл google и satackoverflow но не могу найти решения.
Написал сайт на Node+react+mongo. Соответственно все делал на локале (Запуск сервера
и коддинг). Теперь взял пробное место на хостинге Timeweb. Залил туда проект, установил
на сервере Node + все зависимости проекта. Код работает если вызываю команду node app.js,
который запускает этот код
const express = require('express');
const MongoClient = require('mongodb').MongoClient;
// const path = require('path');
// const logger = require('morgan');
// const multer = require('multer');
const bodyParser = require('body-parser');
const db = require('./config/db');
const app = express();
const port = 8000;
app.use(bodyParser.json());
app.use(bodyParser.urlencoded({extended: true}));
app.use(express.static(`${__dirname}/public`));
const dirname = __dirname;
MongoClient.connect(db.url, (err, database) => {
if (err) return console.log(err)
require('./server/routes')(app, database, dirname);
app.listen(process.env.PORT || port, () => { console.log(process.env.PORT || port) })
})
и выводит в консоль соответствующий порт 8000.
Вопрос собственно в том, как мне сделать чтобы мое приложение запускалось и все рендерилось
под доменом так же как я это видел на локале.
Можно хотябы ссылку на какуюто информаию или туториал.
Извините а такой банальный вопрос.
Всем спасибо заранее!)
Ответы
Ответ 1
Зависит от того, что у вас там за сервер. Для nginx делать так:
Для начала сам nginx установить sudo apt-get -y install nginx.
Открыть конфиг файл sudo nano /etc/nginx/sites-available/default и написать там:
server {
listen 80;
server_name имя_вашего_домена;
location / {
proxy_pass http://127.0.0.1:8000;
proxy_set_header Host $host;
}
}
Перезапустить nginx sudo service nginx restart.
Остаётся только в настройках DNS вашего домена направить его на ip этого сервера.
Здравствуйте. Хостинг находится в США, ping из России согласно тестам 200-300ms.
Следует ли переносить сайт на хостинг в Россию?
Сайт: Wordpress + форум bbPress
Хостинг в США Namecheap
Выскажитесь те кто сидит в Москве и администрирует сервера в США.
Вопрос: является ли критичным пинг в 200-300 мс для пользователей из России? И следует
ли вложить деньги и перенести сайт на хостинг в Москву?
Ответы
Ответ 1
Согласно Google Pagespeed Insights время загрузки страницы должно быть в пределах
до 0.2s (т.е. 200ms). Это учитывается при прохождении гуглоботом по вашему сайту при
индексировании. Да и Яндекс тоже на этот параметр смотрит, т.к. время загрузки страницы
влияет на "восприятие" вашего сайта.
Однако, при работе сайта, когда вы отправляете запрос "получить страницу", эта страница
должна еще и сформироваться, т.е. запрос должен быть обработан сервером - а это еще
некоторое время. А у вас только на передачу запросов и получение ответа будет тратиться
минимум 200-300ms. Так что время загрузки страницы будет куда больше. С другой стороны,
гуглобот скорее всего будет этот сайт обходить с серверов в Америке (если регион сайта
не указан "Россия"), Яндекс же - нет.
Следовательно, для продвижения - этот параметр будет очень критичен. С другой стороны,
если вы не собираетесь продвигать этот сайт или же основная масса посетителей будет
из Америки, тогда можно оставить там.
Если же сайт ориентирован на Россию - то тогда хостинг желательно в России. Ну или
хотя бы в Европе.
С другой стороны, вступил в силу закон, по которому если сайт хранит какую-либо информацию
о Российских гражданах (а это имя, телефон и тому подобное, что как раз можно указать
на любом форуме), то информация должна храниться на серверах, расположенных в РФ. Иначе
может грозить крупный штраф. Такие штрафы обычно ставятся не по факту самого нарушения,
а за каждого человека, которого касается это нарушение. Т.е. пропорционально количеству
человек, оставивших на сайте информацию о себе.
P.S.: Данный закон касается только резидентов РФ, подробнее - в разделе "Трансграничность"
Ответ 2
Пусть страница у вашего пользователя начнёт загружаться через эти 200-300 мс. Если
у вас сайт из статического HTML без картинок и https, то уменьшив RTT, вы увеличите
скорость открытия сайта на идеальном соединении у идеального пользователя (забудем
что RTT ограничивает полосу пропускания TCP).
Теперь вспомним что сайт у вас, скорее всего, динамический, на https, с кучей разного
JS и картинок... Всё это вместе запросто может съесть секунду-другую на загрузку и
подготовку к отображению вашей страницы в
браузере. Гость сайта вашего не обязательно заходит с идеального соединения.
Это всё к тому что RTT не обязательно так важен, как может показаться. Оптимизация
других частей сайта может принести много больше пользы, чем перенос сервера на более
близкую к пользователю площадку.
От теоретических изысканий перейдём к практике. Рассмотрим сайт автора этого ответа,
который живет на момент написания ответа на японском сервере с RTT из Европы в районе
тех самых 200 мс. Сайт из статического HTML, значит у вас будет хуже. Для иллюстрации
на момент тестирования на сервере был отключен OCSP stapling.
WebPagetest показывает нам на понятном графике что DNS запросы заняли 327 мс, установка
соединения предсказуемо заняла порядка одного RTT, а проверка SSL сертификата заняла
целых две трети секунды. (Включение OCSP stapling сокращает время на проверку сертификата
примерно в два раза.)
О чём это нам говорит? Не так страшен RTT как его малюют. Смотрите на что на самом
деле тратится время при открытии страниц сайта. Очень может быть что уменьшение RTT
в два раза не ускорит открытие страниц в те же два раза.
Ответ 3
Если аудитория сайта в России, стоит перенести в Европу.
Стоит ли переносить Россию - вопрос, конечно, очень спорный по понятным причинам
(правило №1 из "9,5 правил ведения безопасного IT-бизнеса в России" гласит: Держите
серверы за границей).
Если Вас устраивает Россия в качестве юрисдикции для ваших серверов - переносите
в Россию.
Если аудитория и там, и там, желательно быть и там, и там.
P.S.: проблема с законом об обработке персональных данных, конечно же, не решится,
если сервера переедут не в Россию. Но раз они и так в США, то, по всей видимости, это
не проблема для автора вопроса.
Доброго времени суток!
Я администрирую сайты у нас в компании.
Недавно нам взломали сайт, и не один. Атакам ежедневно подвергаются все сайты, находящиеся
на хостинге. Выглядит это как добавление php файлов, архивов и целых папок в корни
сайтов и в директории типа images.
Результатами взлома сначала являлась подмена главной страницы для роботов гугл, затем
2 рассылки с нашего почтового сервера и рассылка со ссылкой на нехороший файл на одном
из наших сайтов.
Что было сделано:
Почистили все от вредоносного кода, обновили cms основного нашего сайта, так как
сначала думали, что только он был взломан, запретили доступ к системным папкам по другим ip.
Поменяли все пароли (к ftp, cms, бд).
Дальнейшие действия не очевидны. Наш хостер не дает изолировать друг от друга папки
на хостинге, как и не может ограничить доступ к ftp по другим ip(
Какой следующий шаг?
UPD 4.12.17
Установили на всех сайтах логи доступа.
Прогнали сайты через ai-bolit, появилась почва для размышления и поле для деятельности.
После вычистки и настройки сайтов будем их разносить по разным хостингам и наблюдать.
UPD 18.12.17
На прошлой неделе выложил на хостинг чистые копии сайтов. Ограничил доступы к системным
папкам и отключил register_globals через .htaccess.
С тех пор проблемы со взломом не возникали. Скоро будем переезжать на новый хостинг.
Спасибо всем за помощь. С наступающим вас!
Ответы
Ответ 1
Можно попробовать перекрыть вот этот вектор атаки:
Выглядит это как добавление php файлов, архивов и целых папок в корни сайтов и
в директории типа images.
Но для этого необходима возможность создавать на сервере новых пользователей и настраивать
веб-сервер, т.е. эта инструкция - не для шаред-хостинга.
1. Разделяем пользователя-владельца сайта и пользователя от которого работает веб-сервер.
Второму пользователю запрещается доступ на запись во все директории кроме тех куда
пользователи могут загружать файлы.
В UNIX-подобных ОС без использования ACL такого поведения можно достигнуть включив
обоих пользователей в одну группу, далее первый пользователь делается владельцем файлов
и директорий, и права на файлы устанавливаются 640 (740 на директории или 750 если
важен листинг директории).
2. В тех директориях, куда разрешается загрузка пользовательских файлов - запрещаем
запуск любых скриптов на уровне веб-сервера.
В Apache для этого надо прописать примерно следующее (только изучите свой конфиг
чтобы увидеть реальные типы возможных скриптов - ну или выключите все что не используете):
RemoveHandler .php .phtml .php3
RemoveType .php .phtml .php3
AllowOverride None
Также конфиг выше отключает поддержку .htaccess в этих директориях, потому что в
противном случае при наличии дыр злоумышленник может загрузить этот файл и разрешить
самому себе запускать скрипты.
При использовании Nginx надо закрыть директории со статикой от поиска в них скриптов
через использование ^~:
location ^~ /uploads/ {
try_files $uri =404;
}
Также в случае использования сайтом паттерна Front Controller можно отказаться от
популярного location ~* \.php(/|$) в пользу непосредственного направления нужных маршрутов
на фронт-контроллер (да, для этого придется внимательно изучать используемую CMS):
location / {
fastcgi_pass 127.0.0.1:9000;
fastcgi_param SCRIPT_FILENAME /path/to/index.php;
fastcgi_param PATH_INFO $uri;
}
Если у вас внезапно Windows и IIS - надо убрать все обработчики кроме статических
файлов и заблокировать конфигурацию от изменений:
Важно сделать это именно через location в файле более высокого уровня, чтобы злоумышленник
не мог обойти ограничение через замену файла web.config в доступной для записи папке.
3. После закрытия папок куда пользователи могут загружать файлы от загрузки туда
серверных скриптов надо закрыть их от загрузки html-страниц. Это уже атака не на ваш
сервер, а на ваших пользователей - но это же не означает что от нее не надо защищаться?
В Apache это делается через RemoveType .html (полный список типов уточните в своем
конфиге), в nginx надо будет явно перечислить разрешенные к загрузке типы файлов (types
{ ... }), а в IIS это делается настройкой system.webServer/staticContent по аналогии
со списком обработчиков (там можно как удалить несколько типов так и полностью составить
список с нуля).
Если веб-сервер настроен правильно - то злоумышленнику будет намного труднее пользоваться
имеющимися дырами. А дыр связанных с загрузкой пользовательских файлов можно будет
и вовсе не бояться.
Есть два понятия:
сниппет — кусок кода, который можно использовать повторно,
система контроля версий — система, используемая для того, чтобы несколько программистов работали над одним проектом и использовали один репозиторий.
Вопрос в следующем. Я пробовал пользоваться Github, но это несколько затратно ввиду моих нужд. Нужно, чтобы на некоем сайте можно было начать проект, была примитивная возможность создавать папки, сливать туда файлы с кодом, и этот же код, просматривать онлайн. Сливать именно через браузер, а не через систему контроля версий (часто работаю на разных компьютерах, а устанавливать и настраивать git, желания нет). Сниппеты не катят, потому что это не файлы. А искать, если проект состоит более чем из одного файлы радости не доставляет. Плюс бывают файлы с моделями, а их таким образом уже не зальешь. Заранее спасибо за дельные советы и ссылки.
Ответ
Обычно в таких ситуациях (когда система контроля версий - слишком тяжеловесно) используют Dropbox
UPD
Несколько извращенный вариант, но просмотр кода он-лайн есть, да еще и с примочками: CodeRemarks
Доброго времени суток. Сегодня захожу на свой некий сайт и вижу следующее Данный домен зарегистрирован в интересах клиента.
Зашел в билинг панель хостера и вижу что заказанного мною хостинга физически не существует. Пропали труды 3-х месячной работы над проектом.
На почте хранится куча сообщений о заказе услуги, ее продлению и т.п.
Кто сталкивался с подобным ранее? Какие мне принимать меры по произошедшему и т.д.
Хочу услышать ваши советы и прочее.
UPD
Администраторы уже занимаются решением данной проблемы. В ближайшее время работа аккаунта будет восстановлена.
Приносим извинения за доставленные неудобства.
Жду)
Ответ
ну если есть доказательства на почте, смело пиши им и звони!
Если пойдут на попятную, смело подавай в суд, распечатывай материалы с почты - тогда они запоют другую песню.
//upd
Сначала позвони в саппорт, если в саппорте тебя мягко говоря пошлют, проси старшего по саппорту, если и он такой же тугой, тогда если хостер в твоем городе смело едь к ним!
Приедишь к ним, в руках у тебя уже должна быть бумага в 2х экземплярах о том что случилось и что ты хочешь в этом разобраться! один они берут себе, на втором ставят приходный номер и печать, и ФИО того кто принял заявление. в течении времени они обязаны ответить тебе.
Можешь распечатать в свое доказательство письма с почты, причем в заголовках писем есть от кого отправлено вплоть до IP.
Думаю они быстро решат проблему, иначе 1 отзыв в нете может ой как пагубно отразиться на всем хостере!
@Palmervan если есть доказательства на почте, смело разговаривай с ними на тон выше, чем обычно. Не навязывай им то что ты прав, а говори это! Если они не тупые пойдут на встречу и все сделают, если тупые -суд и они станут еще тупее.
//upd
физически удалить все равно его проблематично в плане бекапов. т.е. тут дело в чем, если пропали данные только у тебя - то дело пахнет керосином, если у 100 клиентов такое же то тут беда вселенского масштаба - но тоже подпадает под нарушение со стороны хостера. А ежели только твой аккаунт - тогда вопрос встанет иначе что они руками искоренили акк + всю инфу и дампы - а это еще +1 в твою карму и выигрыш дела на суде.
Сижу на хостинге, и у некоторых пользователей очень долгая загрузка сайта.
Разбирались, и нашли почему такая проблема, но не нашли решения. На сайт подключается стиль стандартным способом:
В стиле всего 79 строчек, но самую большую нагрузку в стилемов файле беру изображения: background: url(../images/bg.jpg);
И вот каждая картинка грузит около 3-5 секунд (весом 900кб). Не понимаем, с чем связана эта проблема, у 95% пользователей все окей, а у остальных 5% - такая вот беда... При прямом открытии картинки по URL, эту картинку грузит все равно те же 5 секунд, а остальные - шустро (200мс в среднем). В какую сторону стоит копать в такой ситуации?
Ответ
Я бы посоветовал вам оптимизировать весь статический контент на сайте. Сжатие графики В вашем случае кроме сжатия стилей и скриптов посоветую сжимать и графику. К примеру, картинки можно легко сжать без потери качества только за счет удаление exif-данных. На реальном сайте можно сократить размер картинок в среднем на 70%, что на современном сайте равняется примерно 4 МБ. Пример на gulp var
gulp = require('gulp'),
imagemin = require('gulp-imagemin'),
imageminJR = require('imagemin-jpeg-recompress'),
imageminSvgo = require('imagemin-svgo'); // Optimizing images
gulp.task('imagemin', function() {
gulp.src('./img/**/*')
.pipe(imagemin([
imageminJR({
method: 'ms-ssim'
}),
imageminSvgo({
plugins: [
{removeViewBox: false}
]
})
]))
.pipe(gulp.dest('./public/img/'))
});
А для браузеров, которые понимают легковесный формат webp (формат разработан Google), можно сделать еще такой вариант изображений: var
gulp = require('gulp'),
webp = require('gulp-webp'); // Generate Webp
gulp.task('webp', function() {
gulp.src('./img/**/*')
.pipe(webp())
.pipe(gulp.dest('./public/img/'))
});
Оптимизация скриптов Сперва объедините все скрипты в один файл и минифицируйте их. Это помет сократить количество HTTP-запросов и размер файлов: var
gulp = require('gulp'),
concat = require('gulp-concat'),
uglify = require('gulp-uglify'); // Concat JS
gulp.task('js', function(){
gulp.src([
'./js/jquery.js',
'./js/wow.js',
'./js/menu.js',
'./js/scrollspy.js',
'./js/main.js',
'./js/temp/contact.bundled.js',
'./js/owl.carousel.js'
])
.pipe(concat('script.js'))
.pipe(uglify())
.pipe(gulp.dest('./public/js/'))
});
Оптимизация стилей Кроме обычной минификации стилей можно использовать и продвинутую - объединять дубликаты классов и @media. Пример на gulp из моего [web-starter-kit][1]: var
gulp = require('gulp'),
stylus = require('gulp-stylus'), // Минифицирует CSS, объединяет классы. Не ломает CSS, в отличие от cssnano, который, к примеру, может неправильно выставлять z-index
csso = require('gulp-csso'), // Объединяет все @media
cmq = require('gulp-combine-mq'), // Сокращает CSS-селекторы
gs = require('gulp-selectors'), // Проставляет вендорные префиксы
autoprefixer = require('gulp-autoprefixer'), livereload = require('gulp-livereload'),
nib = require('nib'); // Compiling Stylus in CSS
gulp.task('css', function() {
gulp.src('./styl/*.styl')
.pipe(stylus({
use: nib()
}))
.pipe(cmq())
.pipe(csso())
.pipe(autoprefixer('last 3 versions'))
.pipe(gulp.dest('./public/css/'))
});
А если совсем делать нечего, то можно еще и селекторы сократить: // Minify selectors
gulp.task('gs', function() {
var ignores = {
classes: ['active', 'menu', 'nav', 'slide', 'error', 'form-control', 'loader', 'showLoader', 'fadeLoader', 'webp', 'wow', 'owl-*', 'i-*'],
ids: '*'
};
gulp.src(['./public/**/*.css', './public/**/*.html'])
.pipe(gs.run({}, ignores))
.pipe(gulp.dest('./public/'))
});
Кстати, наверняка у вас есть классы, добавляющиеся через JS, поэтому предварительно стоит все такие классы вынести в переменную ignores Кеширование статики на стороне пользователя Также бы посоветовал кешировать скрипты и стили на стороне пользователя, чтобы исключить их повторную загрузку, если они не изменились:
Header set Cache-Control "max-age=2592000"
И включить gzip сжатие на сервере: # сжатие text, html, javascript, css, xml:
AddOutputFilterByType DEFLATE text/html text/plain text/xml application/xml application/xhtml+xml text/css text/javascript application/javascript application/x-javascript
Несмотря на свою деятельность в веб-разработке, пока ещё не достиг глубокого понимания сущности интернета и этот вопрос - один из шагов на пути к осмыслению. В Википедии, в статье "Интернет" среди юридических аспектов и общих свойств интернета приведено:
У Интернета нет собственника, так как он является совокупностью сетей,
которые имеют различную географическую принадлежность.
Если это прочитает человек, не имевший ранее дело с интернетом, он наверняка может прийти в выводу, что всё, что нужно для опубликования своего сайта в интернет - подключённый к интернету компьютер и никаких хостинговых компаний и регистраторов доменных имён. Насколько я уже знаю, для того, чтобы начать "транслировать" свой сайт в интернет, нужно открыть 80-ый порт (например, с помощью веб-сервера Apache, который является ПО). Конечно, безопасность персонального для компьютера такой трансляции - уже другой вопрос. Но что представляет собой технически покупка доменного имени? Почему мы не можем присовить произвольное доменное имя своему сайту хотя бы в пределах некоторых доменных зон и транслировать его со своего компьютера под этим доменным именем? Выходит, у интернета всё-таки есть собственник, который наделяет правом регистраторов доменов продавать эти доменные имена?
Ответ
Собственника у Интернета нет, но есть координатор. Исторически сложилось так, что координатором является ICANN Почему же мы не можем просто так взять произвольное имя? Потому что это имя должно быть известно всем и однозначно разрешаться в IP-адрес компьютера. Для этого служит DNS. И именно за внесение записи в эту глобальную для всего мира таблицу соответствия имён и IP-адресов вы и платите при покупке доменного имени. Можно ли не платить? Можно. Например, можно вписать соответствие имени и IP в локальный файл hosts. Но тогда сайт будет доступен только с тех компьютеров, где мы этот файл изменили. Можно поднять свой собственный DNS-сервер, на котором указать наше имя и использовать этот сервер для всех компьютеров, которым нужен наш сайт. Но вряд ли произвольный пользователь в Сети согласится на это. К тому же, если каждый сайт сделает такой сервер, то для клиента будет абсолютно неудобно этот адрес DNS-сервера постоянно переписывать. (Но это хорошее решение для внутренних сетей организаций.) Поэтому большинство предпочитает заплатить и не мучиться. Есть ещё один способ получить имя бесплатно. Надо найти того, кто уже купил имя второго уровня (или более низкого), например, example.org, договориться с ним и попросить внести запись более низкого уровня, например, vasya.example.org. Это можно сделать, поскольку владелец домена может прописывать любые записи для всех поддоменов.
Не могу найти хорошего хостинга, тот дорогой, а тот не подходит. Решил рискнуть поставить на компьютер сервер, не могли бы вы написать плюсы и минусы этой затеи.
Ответ
Плюсы:
Ты сам себе хозяин.
Много места для твоих проектов.
Минусы:
Постоянный шум компьютера.
Расходы на электричество.
Убиваешь свое железо.
Очень затратно.
Нужно постоянно мониторить, обслуживать сервер.
Постоянный онлайн, нужны средства на оплату трафика (если он не безлимитный)
Я бы не советовал заниматься данным мазохизмом, не пожалей пару баксов и возьми себе нормальный хостинг, меньше геморроя будет. Я бы посоветовал jino.ru. В любом случае это обойдется тебе дешевле, чем свой сервер. И я сомневаюсь что ты будешь использовать всю мощь своего сервера.
Всем привет!
У меня проблемка. Перерыл google и satackoverflow но не могу найти решения.
Написал сайт на Node+react+mongo. Соответственно все делал на локале (Запуск сервера и коддинг). Теперь взял пробное место на хостинге Timeweb. Залил туда проект, установил на сервере Node + все зависимости проекта. Код работает если вызываю команду node app.js, который запускает этот код
const express = require('express');
const MongoClient = require('mongodb').MongoClient;
// const path = require('path');
// const logger = require('morgan');
// const multer = require('multer');
const bodyParser = require('body-parser');
const db = require('./config/db');
const app = express();
const port = 8000;
app.use(bodyParser.json());
app.use(bodyParser.urlencoded({extended: true}));
app.use(express.static(`${__dirname}/public`));
const dirname = __dirname;
MongoClient.connect(db.url, (err, database) => {
if (err) return console.log(err)
require('./server/routes')(app, database, dirname);
app.listen(process.env.PORT || port, () => { console.log(process.env.PORT || port) })
})
и выводит в консоль соответствующий порт 8000.
Вопрос собственно в том, как мне сделать чтобы мое приложение запускалось и все рендерилось под доменом так же как я это видел на локале. Можно хотябы ссылку на какуюто информаию или туториал. Извините а такой банальный вопрос.
Всем спасибо заранее!)
Ответ
Зависит от того, что у вас там за сервер. Для nginx делать так:
Для начала сам nginx установить sudo apt-get -y install nginx
Открыть конфиг файл sudo nano /etc/nginx/sites-available/default и написать там: server {
listen 80;
server_name имя_вашего_домена; location / {
proxy_pass http://127.0.0.1:8000;
proxy_set_header Host $host;
}
}
Перезапустить nginx sudo service nginx restart
Остаётся только в настройках DNS вашего домена направить его на ip этого сервера.
