Month: November 2011

Ошибка апача: [warn] _default_ VirtualHost overlap on port 443, the first has precedence

Такая ошибка вылазит при перезагрузке или переконфигурировании апача.

Причина такой ошибки очень простая – в конфиге апача (httpd.conf, apache2.conf – смотря какой линукс у вас) не хватает строчки:

NameVirtualHost *:443

Добавьте – и будет вам счастье 🙂
http://geckich.blogspot.com/

Настройка mod_proxy в Apache

В общем, был такой таск: есть у нас локальная сетка и маршрутизатор Peplink. В локальной сетке на многих тазиках крутятся сайты, которые должны быть доступны извне. Как это сделать? Разносить по портам – не вариант, т. к. пользователю неудобно всё-таки набирать  URL типа блаблабла:8081. Решение – использовать HTTP-прокси, а на тазик с ним открыть в маршрутизаторе порты 80, 443. Для проксирования обычно используют nginx, но апач тоже отлично справляется с этой задачей.

Так сложилось, что тазик с прокси был Убунтой (клиент категорически н ехотел работать с другими дистрибутивами Linux), а “в Убунте всё не как у людей” (с) 🙂 потому конфигурация её несколько отличается от других дистрибутивов. Но, приняв философию Убунты, я понял, что многие решения в ней очень даже удобны, хотя некоторые мне не нравятся – например, отсутствие пользователя root. Но это уже философия, грозящая холиваром, потому перейдем к делу 🙂

В убунте манипулирование апачем происходит с помощью глобальных команд: включение/выключение виртуал хостов – a2ensite / a2dissite с одним аргументом – пути к конфигу, в котором прописан виртуал хост. Включение/выключение модов или расширений происводится командами a2enmod / a2dismod.

В общем, алгоритм работы такой:

1) Нужно включить необходимые модули апача. Устанавливаем:

sudo apt-get install libapache2-mod-proxy-html libapache2-mod-gnutls

Разрешаем:
sudo a2enmod proxy
sudo a2enmod ssl
sudo a2enmod cache
sudo /etc/init.d/apache2 restart

2) Делаем конфиг виртуал хоста (по 1му файлу на 1 хост!) и помещаем его в /etc/apache2/sites-available. Пример HTTPS конфига проксирования на тазик с Confluence – это такая джавовская веб-морда для программистов и не только, работающая на Apache Tomcat (с портом 8444):


<VirtualHost *:443>

    #мыло админа и документ рут не существующий – т. к. апач требует хоть какой-то обязательно
    ServerAdmin admin@mydomain.com
    DocumentRoot “/etc/httpd/docs/dummy-host.example.com”
    
          #вот здесь внимательно заполняем теми данными, которые у нас есть в ДНС-ах
    ServerName conf.mydomain.com
    ServerAlias www.conf.mydomain.com

    #настройки SSL – включение SSL и пути к файлам ключей
    SSLEngine On
    SSLCertificateFile /etc/ssl/server.crt
    SSLCertificateKeyFile /etc/ssl/server.key

    #включение прокси для данного виртуал хоста и некоторые настройки. Я в них особо не вчитывался – работает так отлично 🙂
    SSLProxyEngine On
    ProxyRequests Off
    ProxyPreserveHost On
    ProxyVia full

    <proxy *>
    Order deny,allow
    Allow from all
    </proxy>

    #чего и куда проксируем / означает что проксируются все запросы к сайту, начиная с корня
    ProxyPass        /  https://192.168.1.132:8444/
    ProxyPassReverse /  https://192.168.1.132:8444/

</VirtualHost>

Замечание: Не забываем создать ssl-сертификаты либо положить с другой машины в папку /etc/ssl/ и выставить права (chmod 700 /etc/ssl/ и на файлы: chmod 600 /etc/ssl/server.crt и chmod 600 /etc/ssl/server.key)

Для HTTP virtual host убираются строчки, связанные с SSL и меняется порт 443 на 80, SSLProxyEngine On меняется на ProxyEngine On. Ну и в директиве ProxyPass https на http – понятное дело.

Затем командой

sudo a2ensite /etc/apache2/sites-available/конфиг_виртуал_хоста 

Активируем наш виртуал хост. После этого нужно перезагрузить апач:

sudo /etc/init.d/apache2 reload

Усё, будет проксировать.

После долгого секса с Debian выяснил, что надо еще дополнительно сделать:

sudo a2enmod proxy_connect
sudo a2enmod proxy_html
sudo a2enmod proxy_ftp
http://geckich.blogspot.com/

Расширение EBS Volume на Amazon AWS

Амазон славится своей масштабируемостью. И вот если нам стало мало места на нашем виртуальном жестком диске, то его очень легко увеличить.

Заходим в AWS, например: https://console.aws.amazon.com/ec2/home?region=us-east-1#s=Volumes

Тут у нас два пути: 1 – создаем снапшот со старого диска, затем разворачиваем его на новом (но придется вручную увеличивать его объем, т. к. он будет как у старого, а остаток пространсва – неразмеченным), 2 – создать пустой диск и скопировать, например rsync’ом данные со старого диска на новый.
Я пошел по 1му более тернистому пути 🙂

Создаем снапшот нашего старого EBS volume. Дожидаемся окончания.

Далее пецкаем Create Volume и там выбираем наш только что созданный снапшот. Ждем окончания (не забывая обновлять страничку).

В контекстном меню EBS раздела выбираем Attach volume – далее вирт машину, куда надо его присоединить и то как она будет видна в /dev (например, /dev/sdf) – только выбираем еще не занятое обозначение! иначе операция залипнет.

Затем логинимся на целевую вирт. машину по ssh и монтируем наш новый раздел. У меня тут вылез косяк такого метода, заключающийся в том, что из-за снапшота на новом разделе выделилось столько же места, сколько и на старом. А остальное осталось неразмеченным, потому пришлось расширять раздел:

1) делаем

fsck -c /dev/sdf 

(sdf – имя, которое мы указывали при аттаче).
2) делаем

resize2fs /dev/sdf

(по умолчанию команда расширяет указанный раздел до конца свободного пространства на диске)

Затем можно еще раз чекнуть ФС – на всякий случай.

Если данные на старом разделе во время всей процедуры могли измениться, то сделаем следующее:

mount /dev/sdf /mnt/sdf/
rsync -av /mnt/oldebs/ /mnt/sdf/

Утилита rsync синхронизирует данные из 1го на 2й раздел, сохраняя права.

Теперь стопнем все службы, которые могут использовать старый диск и отмонтируем старый раздел:

umount /mnt/oldebs

И примонтируем на его место новый:

mount /dev/sdf /mnt/oldebs

Теперь остается подправить файл /etc/fstab – чтобы при загрузке ОС монтировался новый раздел, а не старый.

Идем в AWS консоль и делаем старому разделу Detach Volume.

Усё.

http://geckich.blogspot.com/

Установка и использование антивируса Clamav

Бывает, что rkhunter и chkrootkit недостаточно чтобы точно определить, есть ли зловредный руткит или типа того в вашей системе. Тут нам на помощь приходит антивирус для Linux – Clamav.

Установка. В зависимости от дистрибутива используем одну из следующих команд:

yum install clamav, urpmi clamav, apt-get install clamav, pacman -S clamav

Для обновления антивирусных баз юзаем команду:

freshclam

Для сканирования каталога:

clamscan -r <каталог>

 Также можно использовать следующие опции:

– управление информационными сообщениями

  • –verbose 
  • –no-summary (не выдавать итоговый отчёт) 
  • –infected (сообщать только об обнаруженных вирусах) 
  • –quiet (об обнаруженных вирусах также не сообщается!) 
  • –bell (звенеть при обнаружении вируса; звенит даже при –quiet) 
  • –debug 
  • –log=имя-файла (файл дополняется) – очень полезная штука, иначе вы не узнаете, что у вас заражено в принципе, если файлов много 
  • –stdout 

– действия при обнаружении вирусов

  • –move=имя-каталога (перемещать инфицированные файлы в указанный каталог; д.б. права на запись) 
  • –copy=имя-каталога (копировать инфицированные файлы в указанный каталог; д.б. права на запись) 
  • –remove (удалять файлы с вирусами; не советую)
    http://geckich.blogspot.com/

    Использование hosts.deny и hosts.allow

    Бывают ситуации, когда надо заблокировать доступ злоумышленникам на наш компьютер. Если разбираться с правилами iptables не нужно, то самое простое решение – добавить ip злоумышленника в hosts.deny. А hosts.allow служит как раз для противоположной цели

    Синтаксис этих файлов очень прост:

    <служба или ALL>: <IP-адрес или имя хоста или подсеть>

    Так, например, если мы хотим блокировать все smtp-пакеты, идущие к нашему серверу от mail.test.ru, нам необходимо ввести в файл hosts.deny следующую строчку:

    smtp: mail.test.ru

    Для ssh:

    sshd: 210.123.134.56

    А если мы хотим запретить подключение по ssh всем, кроме локальной сети, то:

    /etc/hosts.deny
    sshd: ALL
    /etc/hosts.allow
    sshd: 192.168.1.
    В этом примере 192.168.1. значит 192.168.1.0..255
    Всем удачи 🙂
    http://geckich.blogspot.com/

    SCP – утилита копирования файлов по LAN/WAN

    Часто возникает задача скопировать файл (например, конфиг) с одной Linux машины на другую.  Если надо скопировать 1-2 файла, то поднимать FTP сервер нет смысла – проще воспользоваться командой SCP, которая копирует файлы по протоколу SSH.

    Пример копирования из машины-источника (назовем ее так) на нашу:

    scp -P 230 root@192.168.1.5:/etc/ssl/server.key /etc/ssl/

    где

    • -P 230 – указание порта (если SSH на машине-источнике работает не по стандартному 22-му, а как в примере по 230);
    • root – имя пользователя на машине-источнике;
    • 192.168.1.5 – адрес машины источника;
    • /etc/ssl/server.key – путь к файлу, который надо скопировать;
    • /etc/ssl/ – путь, куда копировать (на нашей машине).

    Вот так вот всё просто 🙂

    ssh -t user@192.168.1.2 scp /home/user/some_file user2@192.168.1.3:/home/user3/

    http://geckich.blogspot.com/

    Установка SVN + mod-dav в Linux

    Недавно был такой таск – установить на клиентский тазик связку svn + mod_dav для апача с соединением по HTTPS. ОС там была Ubuntu, а в ней настройка апача не совсем как везде 🙂 Так что смотрите.

    Пошагово делаем так:

    1. Устанавливаем subversion:

    sudo apt-get install subversion libapache2-svn apache2

    2. Включаем ssl модуль для апача. Если нам ssl не нужен, то пропускаем пункты 2-4.

    sudo a2enmod ssl

    3. Копируем наш ключ в /etc/apache2/ssl либо создаем новый командой:

    sudo make-ssl-cert /usr/share/ssl-cert/ssleay.cnf /etc/apache2/ssl/apache.pem

    4. Выставляем права доступа к сертификату иначе “кина не будет”.

    sudo chmod 600 /etc/apache2/ssl/apache.pem

    5. Включаем модуль dav для апача:

    sudo a2enmod dav dav_svn

    6. Добавляем конфиг для mod_dav в файл apache2.conf в конец или в файл /etc/apache2/mods-available/dav_svn.conf

    <Location /opt/testrepo>
    DAV svn
    SVNPath /opt/testrepo/
    AuthType Basic
    AuthName “Subversion Repository”
    AuthUserFile /opt/testrepo/svnpasswd
    require valid-user
    SSLRequireSSL                  #закомментировать если не надо ssl
    Order deny,allow
    </Location>


    7. Перезагружаем апач после внесения всех изменений:

    sudo /etc/init.d/apache2 reload

    8. Создаем репозиторий svn и его структуру:

    sudo svn mkdir file:///opt/testrepo -m “Testing Initial SVN Structure”
    sudo svnadmin create /opt/testrepo

    Далее импортируем существующий код в репозиторий:

    sudo svn mkdir file:///opt/testrepo/project -m “Project zero”
    sudo svn import /home/user/project file:///opt/testrepo/project

    Содержимое папки /home/user/project будет добавлено в папку /opt/testrepo/project Просмотреть что мы наимпортировали можно командой:

    sudo svn ls file:///opt/testrepo/poject/

    9. Создаем пользователя:

    sudo htpasswd -cm /opt/testrepo/svnpasswd usera
    Когда будем создавать 2го и т. д., то необходимо убрать опцию -c – она нужна для создания файла. А опция -m нужна для указания криптовать пароли md5 алгоритмом.

    Теперь наш репозиторий будет доступен по адресу https://ourdomain.int/opt/testrepo после авторизации.

    Если нужно добавить еще репозитории, то повторяем шаги 6-9 только с новыми путями, проверьте внимательно.

    Вроде бы усё… Ну, может что-то забыл, но в таком случае гугл вам точно поможет – а то память не резиновая 🙂

    http://geckich.blogspot.com/

    Настройка шлюзов при VPN соединении – если при подключении к VPN пропадает интернет

    Сегодня столкнулся с такой вот не совсем очевидной и в то же время простой проблемой: Управлял я Windows 2008 сервером по RDP. И мне понадобилось соединиться по VPN с другой сетью (PPTP). Создал я VPN подключение, включил его… И доступ по RDP пропал 🙂 Фишка оказалась в том, что при включении RDP винда по умолчанию роутит все пакеты на шлюз VPN’a, а не на наш старый. Я уже думал открывать консоль и писать всякие там роуты, но нашел способ попроще.

    Заходим в Панель управления, Цент управления сетями и общим доступом, Свойства адаптеров и вызываем параметры нашего VPN-соединения. Далее клацаем на вкладке Networking (как по-русски – не помню 🙂 ), и вызываем свойства протокола TCP/IP.

    Нажимаем Advanced (Дополнительно)

    И снимаем галочку Use default gateway on remote network.

    Всё! Теперь пакеты сами будут идти куда надо 🙂 Для локальной сети, к которой ведет VPN будут идти через VPN-соединение, а все остальные – по вашему стандартному соединению. Винда сама там раздупляет что куда кидать 🙂

    http://geckich.blogspot.com/