Задать вопрос
  • Git для небольшой команды?

    alexhemp
    @alexhemp
    Реально работающая схема такая

    1. На Web-сервере у каждого разработчика есть аккаунт
    2. В home директории разработчика есть папка Sites
    3. Web-сервер с помощью VirtualDocumentRoot отображает запросы вида user.example.com в /home/user/sites/example.com — это и есть сайты разработчиков. От внешнего мира их легко закрыть http-авторизацией
    4. Разработчики публикуют свои рабочие копии через realsync а не через git — есть статья на хабре
    5. Есть сайт devel.example.com — он деплоиться git из ветки devel — это ветка подготовки релиза, после слияния изменений. Деплой — хуками в интеграционном репозитории, сам сайт — рабочая копия ветки devel
    6. Есть сайт example.com — он деплоиться git из ветки master — это ветка продакшн-релиза. Деплой — хуками в интеграционном репозитории, сам сайт — рабочая копия ветки master

    Все работает автоматически, каждый разработчик работает независимо. Разработчики пушат на сервер свои ветки, руководитель вливает в develop для тестирования.

    6.
    Ответ написан
    5 комментариев
  • Как понять свой уровень знания какой либо технологии, и надо ли знать ее на 100%?

    T_Vova_M
    @T_Vova_M
    Для начала представлюсь.Я-новичок в веб-программировании(так же как и Вы).Тоже был заинтересован в данном вопросе в своё время.
    Вот что скажу:Всё зависит от Ваших целей
    Какие могут быть цели:
    1.Если в ваших намерениях - добиться высокого уровня в веб-разработке для подальшей работы в данной области , то вам желательно знать всё и вся.
    2.Если Вы изучаете данную область в цели заработка на фрилансе , то можно знать основы.Но основы как front-end так и back-end (если не ограничиваться одной вёрсткой).Но при этом нужно осваивать фреймворки и библиотеки.
    3.Если Вы желаете специализироваться на одной области (например JavaScript), то для успешного заработка Вам нужно быть профессионалом в данной области.
    4.Ваши намерение-сделать сайт.Просто для себя.В таком случае есть конструкторы и различные библиотеки.При этом можно и не знать основ веба.

    Как-то так.Из личного опыта.
    Ответ написан
    3 комментария
  • Почему iptables не блокирует входящий трафик с IP адреса на 80 порт?

    martin74ua
    @martin74ua Куратор тега Linux
    Linux administrator
    -d destination
    ваше правило гласит:
    входящие пакеты направленные на адрес (ип, что вы баните) и на порт 80 - отбросить.

    Вы вообще как это себе представляете?
    -s ban_ip и все будет хорошо
    Ответ написан
    Комментировать
  • Как в Jevix проверить атрибут тега на содержание слова?

    27cm
    @27cm
    TODO: Написать статус
    Можно. Проверку осуществлять где-то здесь надо:
    https://github.com/ur001/Jevix/blob/master/jevix.c...
    Ответ написан
    Комментировать
  • Запрет обращения к сайту по IP адресу сервера (только по домену), как реализовать?

    saboteur_kiev
    @saboteur_kiev
    software engineer
    Сделайте виртуальные хосты. Виртуальный хост с пустым сайтом сделайте по умолчанию, а виртуальный хост с доменом - тот, который вам нужен.
    Таким образом по любому доменному имени, которое приведет на ваш IP, пользователю отобразится пустой сайт (ну или с предупреждением), а по нормальному домену - нормальный сайт.
    Ответ написан
    Комментировать
  • Запрет обращения к сайту по IP адресу сервера (только по домену), как реализовать?

    @azazelpw
    Linux SA
    Поищите информацию по nginx размещению нескольких сайтов на одном хосте.
    У вас исходя из конфига, все что приходит на 80 порт, отправляется на сайт.
    Nginx и два сайта на одном домене
    informatikum.ru/linux/138-neskolko-domenov-na-odno...
    Ответ написан
    Комментировать
  • Связка Nginx+Apache. Странное поведение virtual hosts - почему?

    nowm
    @nowm
    Я сначала немного «теории» опишу, а в конце скажу, что в ваших конфигах нужно поправить.

    Вообще, у вас Apache не должен принимать никаких запросов от сторонних серверов. Связка Apache + Nginx делается потому, что Nginx очень хорошо отдаёт статичный контент, а Apache выигрывает в работе с PHP. К тому же, Apache даёт возможность использовать файлы .htaccess, которые позволяют очень гибко конфигурировать работу на уровне директорий одного сервера.

    Так вот. Суть связки Apache + Nginx в том, что Apache обрабатывается входящие запросы только от одного сервера. Обычно они оба ставятся на одной машине, и в этом случае Apache должен принимать запросы только от 127.0.0.1. Он не должен заботиться о том, чтобы обрабатывать имена dev1.site, dev2.site и так далее. Эта задача лежит на Nginx, который будет перенаправлять внешние запросы соответствующим образом.

    Для этого Apache конфигурируется таким образом, чтобы каждый его виртуальный хост слушал свой порт. Например, я строю всю систему таким образом, чтобы у меня было два сервера: task.site и dev.site. Для этого я делаю так:

    /etc/apache2/ports.com:
    NameVirtualHost 127.0.0.1:8080
    NameVirtualHost 127.0.0.1:8090
    Listen 127.0.0.1:8080
    Listen 127.0.0.1:8090


    Это значит, что у меня будет два инстанса, один из которых будет обслуживать имя dev.site, а другой — task.site (при этом, сам Apache как бы будет не в курсе, какой он домен обслуживает. Он знает только что запрос на порт 8080 нужно так обработать, а на 8090 — ещё как-то). Всё, что теперь от апача понадобится — сделать виртуальные хосты, чтобы определить папки, из которых будут вызываться скрипты для каждого из сайтов.

    /etc/apache2/sites-enabled/default.conf:
    <VirtualHost 127.0.0.1:8090>
    	. . .
    	DocumentRoot /usr/share/redmine/public
    	. . .
    </VirtualHost>
    <VirtualHost 127.0.0.1:8080>
    	. . .
    	DocumentRoot /var/www/dev.site
    	. . .
    </VirtualHost>


    Всё. Если запрос будет на 127.0.0.1:8080, то будут выполняться скрипты из папки /var/www/dev.site. Если на 127.0.0.1:8090, то — /usr/share/redmine/public. Сам Apache вообще не в курсе, какие он домены обслуживает, так как снаружи его не видно.

    Далее вступает в работу Nginx. Он отвечает за то, чтобы определить по имени сайта, куда отправлять запрос.

    /etc/nginx/sites-available/default.conf:
    server {
    	listen 80;
    	server_name dev.site;
    	server_name_in_redirect off;
    
    	location / {
    		proxy_pass http://127.0.0.1:8080/;
    		proxy_redirect off;
    		proxy_set_header Host $host;
    		proxy_set_header X-Real-IP $remote_addr;
    		proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    		client_max_body_size 10m;
    		proxy_connect_timeout 90;
    	}
    }
    
    server {
    	listen 80;
    	server_name task.site;
    	server_name_in_redirect off;
    	
    	location / {
    		proxy_pass http://127.0.0.1:8090/;
    		proxy_redirect off;
    		proxy_set_header Host $host;
    		proxy_set_header X-Real-IP $remote_addr;
    		proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    		client_max_body_size 10m;
    		proxy_connect_timeout 90;
    	}
    }


    Как видно из листинга, он для dev.site делает proxy_pass http://127.0.0.1:8080/, а для task.siteproxy_pass http://127.0.0.1:8090/.

    Теперь о том, что нужно поправить в ваших конфигах. В апаче нужно все сервера раскидать по отдельным портам. Сначала нужно прописать NameVirtualHost и Listen для каждого из них. При этом, обязательно нужно указывать не *:8080 или *:8081, *:8082, а конкретно 127.0.0.1:8080, 127.0.0.1:8081 и т.п., потому что «*» позволяет делать прямые запросы с любой машины, а «127.0.0.1» разрешает принимать соединения только с localhost.

    То же самое — в блоках VirtualHost. Вместо <VirtualHost *:8080> нужно писать <VirtualHost 127.0.0.1:8080>

    Из блока VirtualHost нужно выкинуть ServerName и ServerAlias, так как всё это будет обрабатываться на уровне Nginx.

    В итоге вы получите такую ситуацию, что напрямую у вас sub.myhost.ru:8080 открываться не будет, так как Apache принимает запросы только от localhost. Он будет открываться только по запросу от Nginx, который будет определять какой сервер куда проксировать.

    В вашем конфиге Nginx вместо server_name *.myhost.ru; нужно писать полное имя хоста. И для каждого хоста нужно создать отдельный блок server {}.

    В конфигах Nginx ещё не забудьте приписать обработку статики (хотя у вас она и так прописана). Я из листинга этот момент выкинул, но его вообще нужно добавить, потому что одна из прелестей Nginx — как раз обработка статики. В каждый блок server {} можно добавить что-нибудь вроде:

    location ~* ^.+\.(jpg|jpeg|gif|png|ico|css|zip|tgz|gz|js|pdf)$ {
    	root /var/www/dev.site;
    }


    И далее, если вы хотите добавить подсервер: создаёте виртуальный хост апача на свободном порту, а в Nginx добавляете для него блок server {}.

    В данный момент у вас просто небольшая каша получилась в конфигах.
    Ответ написан
    8 комментариев
  • MYSQL. Удалить дубли строк?

    bigbaraboom
    @bigbaraboom
    CREATE TEMPORARY TABLE tmp_tab AS SELECT DISTINCT * FROM your_table;

    DELETE FROM your_table;

    INSERT INTO your_table SELECT * FROM tmp_tab;

    DROP TABLE tmp_tab;
    Ответ написан
    3 комментария