Столкнулся с проблемой при доступе к ftp серверу – vsftpd.
При попытке соединения получал ошибку:
FTP command: Client "1.2.3.4", "PORT 172,16,5,239,15,188"
FTP response: Client "1.2.3.4", "500 Illegal PORT command."Подняли изолированный хост ESXi в DMZ. Выход в сеть через шлюз. Шлюз на FreeBSD, подключен к DMZ (сеть 172.16.5.0/24) и основной LAN 10.0.0.0/24 (в лан – vSphere, остальные хосты esxi, файловый сервер (NFS). Задача – заставить хост ESXi в изолированной сети работать с NFS хранилищем в удаленной сети.
Шлюз. FreeBSD. KernelNAT:
${fwcmd} add nat 1 ip from any to any
Эта строка в ipfw позволяет роутить и натить все на всех трех интерфейсах – интерфейс в интернет, и два интерфейса – в DMZ и локальную общую сеть.
Далее ESXi. Для работы с маршрутами в ESXi есть команда esxcfg-route. Из GUI – в консоли и через vSphere мы можем настроить дефолтный шлюз. Чтобы настроить дополнительный маршрут – нужен ssh (или наверное через CLI тоже можно). Я делал в ssh.
Просмотр маршрутов:
#esxcfg-route --list
Добавляем маршрут в LAN сеть:
#esxcfg-route -a 10.0.0.0/24 172.16.5.1
172.16.5.1 – айпи шлюза в ДМЗ. Командой говорим – все что для 10.0.0.0/24 шлем на 172.16.5.1.
После этого можно пинговать интерфейс шлюза в сети 10.0.0.0/24 (у меня это 10.0.0.2).
Далее. Теперь для того чтобы хост из LAN (NFS сервер в нашем случае) знаку куда отправлять ответные пакеты настраиваем маршрут на нем.
Пусть это хост 10.0.0.10. У меня это CentOS. Делаем:
#route add -net 172.16.5.0 netmask 255.255.255.0 gw 10.0.0.2
Указываем именно gw (просто указания интерфейса недостаточно).
Все. После этого пинг будет проходить от хоста из ДМЗ до NFS сервера и обратно.
Далее правим exports для того чтобы дать доступ к NFS машинам из сети DMZ (172.16.5.0/24).
/storage 172.16.5.0/24(rw,insecure,async,no_root_squash)
И применим изменения:
#exportfs -r
Теперь идем на наш xост ESXi и подключившись клиентом (через шлюза по впн) добавляем NFS хранилище. Все должно подмонтироваться без проблем.
PS: На винде маршрут к удаленной сети добавляем командой (пример):
route add 10.0.0.0 172.16.5.1
В стандартных репозитариях CentOS может не оказаться нужного софта. Например, мне нужен был monit.
Решаем подключением дополнительного репозитария – например DAG:
Создаем файл описывающий репозитарий:
#touch /etc/yum.repos.d/dag.repo
Пишем в файл:
[dag]
name=Dag RPM Repository for Red Hat Enterprise Linux
baseurl=http://apt.sw.be/redhat/el$releasever/en/$basearch/dag
gpgcheck=0
enabled=1Все. Теперь можно искать нужный нам пакет:
#yum info monit
Время в этом году не переводилось на зимнее. А не обновленные машины – перевелись. Пробую обновить время:
#ntpdate ntp2.imvp.ru
смотрим:
#date
Время отстает ровно на час.
Оказалось в CentOS надо обновить пакет tzdata
#yum update tzdata
Проверяем:
#zdump -v /etc/localtime | grep 2011
Проверяем время командой date – все должено быть ок.
Далее можно подстроить часы в BIOS – смотрим дату:
#hwclock
Пишем время в BIOS:
#hwclock --systohc
Понадобилось запустить несколько экземпляров squid на одной машине – на одном интерфейсе с алиасом. Всё это на CentOS.
Сначала настраиваем алиас на CentOS.
Себе на память – как управлять запуском служб в Linux, в частности в CentOS. Есть команда chkconfig. Делаем:
chkconfig --list radvd
radvd 0:off 1:off 2:off 3:off 4:off 5:off 6:offВидим уровни запуска и состояние, в нашем случае radvd отключен на всех уровнях.
Делаем:
#chkconfig radvd on
# chkconfig --list radvd
radvd 0:off 1:off 2:on 3:on 4:on 5:on 6:offВидим состояние служб изменилось. Теперь при старте системы на данных уровнях служба запустится автоматически.
В процессе настройки DHCPv6 на CentOS получил ошибку:
Warning: dhcp6s listening on ALL interfaces
И не работающий dhcpv6:
#service dhcp6s start
dhcp6s: Warning: dhcp6s listening on ALL interfaces
Starting dhcp6s: [ OK ]
# service dhcp6s status
dhcp6s dead but subsys lockedВсё оказалось просто – в файле /etc/sysconfig/dhcp6s обязательно прописываем интерфейс на котором слушаем:
DHCP6SIF=eth0
DHCP6SARGS=PS: Никак не могу привыкнуть к тому что в CentOS конфиги размазаны по нескольким файлам. Во FreeBSD всё как-то более логично…
Если нам нужно быстро сгенерить пароль на пример в Linux делаем:
date +%s | sha256sum | base64 | head -c 8 ; echo
Получаем пароль длиной 8 символов. Если сделать:
date +%s | sha256sum | base64 | head -c 16 ; echo
Получим 16 символов.
Во FreeBSD пароль можно сгененрировать такми способом:
< /dev/urandom tr -dc _A-Z-a-z-0-9 | head -c${1:-8};echo;
Если нужен пароль длиннее (например 16), делаем:
< /dev/urandom tr -dc _A-Z-a-z-0-9 | head -c${1:-16};echo;
Почему-то одно время мне на глаза постоянно попадался какой-то дикий метод создания архива типа tar.gz через перенаправление стандартного ввода-вывода. Но на самом деле создать архив tar.gz очень просто (копирую себе на память поскольку как-то не приучил себя делать все эти стандартные tar -xzf archive.tar.gz в процессе установки чего-либо из сырцов…
Собственно как создать архив:
#tar czf /home/archive.tar.gz /path /to/the/dir
Например архивируем веб директорию с сохранением файловой иерархии:
#tar czf /home/archive.tar.gz /usr/local/www/apache22/data
Распаковываем (в текущую директорию):
tar -xzf /home/archive.tar.gz
Есть тривиальная задача – отследить на шлюзе какой хост потребляет максимальную полосу пропускания. К примеру, если трафик мы не шейпим, но периодически ощущаем, что кто-то, к примеру, запустил торрент клиент и нагружает канал.
Есть пара очень полезных утилит – nettop и jnettop. Первая просто показывает общую загружнность канала, какие порты сервисы занимают наибольшую полосу. Вторая показывает загрузку канала по соединениям – порт, ip адреса, скорость входящего и исходящего соединения и т.д. Обе есть в портах, обе просто ставятся. Запускаем и следим за наиболее прожорливыми соединениями.
Есть ещё пара утилит с псевдографикой – slurm и nload.
Быстро порезать особо активных можно парой правил в ipfw:
${fwcmd} pipe 5 config bw 2Mbit/s mask dst-ip 0xffffffff
${fwcmd} add pipe 5 ip from 172.16.5.213 to anyЧтобы не вспоминать записываю. Надо было удалять старые файлы ежедневных бэкапов которые делал MSSQL и складывал на шару самбы.
Добавляем в crontab:
######################
#Delete Daily Backups
######################
#Daily
0 33 * * * root find /storage/samba/backup/DailyBackup-* -type f -mtime +7 -delete
#Weekly
0 33 * * * root find /storage/samba/backup/WeeklyBackup-* -type f -mtime +15 -delete
#Monthly
0 33 * * * root find /storage/samba/backup/MonthlyBackup-* -type f -mtime +45 -deleteБудет искать в указанных папках по заданной маске все файлы старше 7,15, 45 дней и удалять…
Поймал ошибку от vnstat:
Error: Unable to read database "/var/lib/vnstat/eth0"
Собственно, если vnstat ругается на то что не может создать базу нужно выполнить команду:
vnstat -u -i eth0
Ключ -u создаст файлы базы если их нет – eth0 и файл бэкапа базы .eth0
На CentOS лежат в /var/lib/vnstat/
Создавать руками – бесполезно, будет ругаться:
Error: Database load failed even when using backup. Aborting.
Если у нас statefull iptables (iptables с сохранением состояния соединения) под большой нагрузкой и система выдает следующее:
ip_conntrack: table full, dropping packet
Это значит забивается таблица состояний пакетами. Можно пробовать лечить:
/etc/sysctl.conf
net.ipv4.ip_conntrack_max=131072
/etc/modules.conf:
options ip_conntrack hashsize=16384Чтобы изменения вступили в силу делаем:
#sysctl -p
Но как правило проблема скорее всего не в том что не хвататет ресурсов, а в том что есть проблемная запись в правилах фаерволла, активность зомбимашины, DDOS и т.д.