Наконец то сбылась мечта любителей создавать внутренние локальные сети — настоящий, православный openvpn выпустил собственный docker контейнер с веб мордой, откуда любой желающий сможет установить в две команды его. Вероятно, что давать ссылки на такую новость здесь не следует. Ограничимся скрин-шотом.

При небольших атаках зачастую достаточно добавить ограничение по количеству подключений с одного ip адреса. Школьники попыхтят еще пару часов и их интерес к ресурсу пропадает. Конечно, такое случается нечасто, но тем не менее. Решил записать способ ограничений, прекрасно описанный коллегами, ссылку на статью с картинками добавлю в конце заметки.

Итак, чтобы не разводить пустую болтовню — решение от коллег

# Добавляем следующие правила в iptables
iptables --flush
iptables --new-chain RATE-LIMIT
iptables --append RATE-LIMIT \
    --match hashlimit \
    --hashlimit-mode srcip \
    --hashlimit-upto 50/sec \
    --hashlimit-burst 20 \
    --hashlimit-name conn_rate_limit \
    --jump ACCEPT
iptables --append RATE-LIMIT --jump DROP

И теперь можно посмотреть результат:

netstat -plan | grep -oE ":443|:80" | wc -l                                     
24                                                                       

Количество запросов на web порты сервера упало с тысячи с небольшим до двухзначной величины. Похоже на правду. Всем огромных успехов и удачи в борьбе с ddos атаками.

На всякий случай напомню — выделенные серверы в России, ЕС и США по скромным ценам можно взять в аренду здесь

Если установить панель HesitaCP, то с настройками по-умолчанию отчего то не получалась почта, отправляемая с google (и не только оттуда). Почта возвращалась с ошибкой 454 TLS currently unavailable

Пришлось покурить логи Exim, которые находятся тут: /var/log/exim4/mainlog . Было обнаружено, что у exim нет прав на чтение файла сертификата TLS:

TLS error on connection from mail-pg1-f170.google.com [209.85.215.170] (cert/key setup: cert=/usr/local/hestia/ssl/certificate.crt key=/usr/local/hestia/ssl/certificate.key): Error while reading file.

Мгновенно даем права на чтение командами:

chmod 664 /etc/exim4/domains/*/aliases
chmod 664 /usr/local/hestia/ssl/certificate.crt
chmod 664 /usr/local/hestia/ssl/certificate.key

И для порядка можно перезагрузить exim4

Давеча потребовалось мне раздавать IP адреса по dhcp в локальной сети ДЦ OVH. А адреса с маской 255.255.255.255. И, как водится, шлюз у них один на всех (чтобы масками не добавлять, перерасход же получается — из 8 адресов только 5 используется). Так еще из локалки выпускают только под определенным маком, иначе на шлюзе блочат так, что не видно интернета.

В дата центре OVH шлюз (GATEWAY_IP) у всех IP адресов выделенного сервера начинается так же, как основной IP сервера, а заканчивается на .254. Например для сервера с IP 198.27.92.15 у всех IP будет шлюзом 198.27.92.254 Это очень хороший ход, к слову. Удобно конфигурировать.

После того, как был установлен Proxmox 6 из коробки OVH, я накатил isc-dhcpd server:

apt install -y isc-dhcp-server
cp /etc/dhcp/dhcpd.conf{,.backup} 
echo '' > /etc/dhcp/dhcpd.conf
touch /var/lib/misc/dhcp.leases
nano /etc/dhcp/dhcpd.conf

Теперь нужно написать конфиг серверу, чтобы он раздавал IP адреса для виртуальных машин в сети. Пример я напишу ниже. Сразу оговорюсь — конфиг не идеален, так как работает не со всеми ОС. В частности, на FreeBSD сеть не взлетает, так как Фря не принимает маршрут на такой шлюз. Попытки подсунуть ей маршруты через dhcp не помогли. Адрес IP получает, а настройки сети нет. Если кто то знает, как пропихнуть все-таки маршрут — напишите, пожалуйста, в комментарии.

# мой конфиг isc-dhcpd
# Здесь 192.168.246.xxx - адреса для виртуалок (FAILOVER_IP в терминах OVH)
# 10.10.10.254 - шлюз основного IP сервера (GATEWAY_IP )
option classless-routes code 121 = array of unsigned integer 8;
option classless-routes 24, 192,168,246,	10,10,10,254,
                        0,                      10,10,10,254;
subnet 0.0.0.0 netmask 0.0.0.0 {
        range 192.168.246.170 192.168.246.175;
        option subnet-mask 255.255.255.255; 
        option broadcast-address 192.168.246.255;
        option domain-name-servers 8.8.8.8, 1.1.1.1, 208.67.222.222;
        option domain-name "srv22.vps-server.ru";
        option routers 10.10.10.254;
        default-lease-time 120;
        max-lease-time 600;
}
host VM0 {hardware ethernet 02:00:00:01:01:5b; fixed-address 192.168.246.170; }
host VM1 {hardware ethernet 02:00:00:01:01:ef; fixed-address 192.168.246.171; }
# 

Обращаю пристальное внимание, на то, что для каждого дополнительного IP address нужно указать MAC. Конечно же, именно этот MAC нужно присвоить виртуалке при её создании. Для примера в конце конфига добавлены две строки виртуальных машин VM0 и VM1.

Необходимо заметить, что ISC-dhcp-server довольно капризная в настройке вещь. И понять по выхлопу лога ненавистного systemd почему оно не взлетает не представляется возможным. Поэтому приходится прибегать при отладке к использованию костылей.

# Запуск isc-dhcpd для отладки конфига:
# Для отладки помогает отлично !
/usr/sbin/dhcpd -lf /var/lib/misc/dhcp.leases -cf /etc/dhcp/dhcpd.conf

После того, как конфиг отлажен и работает, можно убить процесс dhcpd и запустить его в режиме демона:

# Убиваем процессы dhcpd 
killall dhcpd -9
/etc/init.d/isc-dhcp-server restart
[ ok ] Restarting isc-dhcp-server (via systemctl): isc-dhcp-server.service.

Отмечу также, что MAC адреса необходимо получить в клиентской панели управления OVH.

Для работы сети с виртуалкой на FreeBSD следует в ней добавить два маршрута:

route add -host GATEWAY_IP/32 -interface em0
route add default GATEWAY_IP

Или добавить в /etc/rc.conf следующие строки:

ifconfig_em0="inet FAILOVER_IP netmask 255.255.255.255 broadcast FAILOVER_IP"
static_routes="net1 net2"
route_net1="-net GATEWAY_IP/32 -interface em0"
route_net2="default GATEWAY_IP"

На этом всё. Напоминаю, выделенные серверы в России с безлимитным трафиком и виртуальные серверы с честной виртуализацией KVM в различных локациях лучше всего приобретать в компании vps-server.ru. Эти ребята работают более 15 лет на рынке хостинга, имеют огромный опыт администрирования и эксплуатации серверов.

Внимательным читателям :o) сообщаю промокод со скидкой 30% на весь срок аренды некоторых выделенных серверов этой компании в России — diman-rulit2021

Естественно, клиенты теряют пароли от виртуальных машин, работающих на виртуализации KVM под управлением гениальной, мощной, удобной системы управления proxmox.

Само собой, довольно просто загуглить варианты с редактированием загрузчика в VNC, добавлением init=/bin/sh в конец строки. Затем перемонтируем корень в rw командой mount -rw -o remount / и собственно, меняем пароль стандартной командой passwd

Однако этот способ годится для современных ОС. У нас же, как всегда — случай нестандартный, ядро linux старое (2.4) и не монтировался /proc с сообщением «mount could not open /proc/partitions»

Соответственно, заходим в консоль хостовой ноды по ssh, отключаем виртуалку в вебмордочке proxmox, обращая внимание на ID. В моем случае -102.

Образ диска у виртуалки находится в директории /var/lib/vz/images/102 и представлен одним файлом — /var/lib/vz/images/102/vm-102-disk-0.qcow2

Нужно смонтировать этот диск, сделать chroot в систему и сменить пароль. Приступаем? Дааа!

Смонтировать диск напрямую не удастся, там ведь несколько разделов:

mount  /var/lib/vz/images/102/vm-102-disk-0.qcow2 /mnt
mount: wrong fs type, bad option, bad superblock on /dev/loop2,
       missing codepage or helper program, or other error

       In some cases useful info is found in syslog - try
       dmesg | tail or so.

Нужно подгрузить модуль ядра nbd и посмотреть разделы на диске qcow2. Действуем так:

modprobe nbd max_part=8
#  подключаем диск в /dev/nbd0
qemu-nbd --connect=/dev/nbd0 /var/lib/vz/images/102/vm-102-disk-0.qcow2
# Смотрим разделы на нем:
fdisk /dev/nbd0 -l
Disk /dev/nbd0: 32 GiB, 34359738368 bytes, 67108864 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000

Device      Boot    Start      End  Sectors  Size Id Type
/dev/nbd0p1 *          63   208844   208782  102M 83 Linux
/dev/nbd0p2        208845 63022994 62814150   30G 83 Linux
/dev/nbd0p3      63022995 67103504  4080510    2G 82 Linux swap / Solaris

Вот тут мы и видим нужный нам раздел — /dev/nbd0p2, так как первый это загрузчик boot, а третий — swap

Как говорится, остальное — дело техники:

# Монтируем раздел в /mnt
mount /dev/nbd0p2 /mnt
# Делаем chroot в виртуальный диск
chroot /mnt
# меняем пароль в новой виртуалке
bash-2.05b# passwd
Changing password for user root.
New password: 
Retype new password: 
passwd: all authentication tokens updated successfully.
bash-2.05b# exit
exit
# отмонтируем диск
umount /mnt

На этом всё. Осталось только включить виртуалку и войти в нее с новым паролем.

Важное добавление. Иногда, при работе в виртуальном КВМ, нужно пробросить дополнительный диск для программ, которые нужно использовать в виртуальной машине, например — с Windows. действуем так:

#
# создаем место, куда смонтируем диск
mkdir /mnt/ramdisk
# создаем в памяти диск нужного размера (здесь - 4Gb)
mount -t tmpfs -o size=4G tmpfs /mnt/ramdisk
# подгружаем модуль nbd
modprobe nbd max_part=8
# создаем  диск для монтирования в VM
qemu-img create -f qcow2 /mnt/ramdisk/disk1.qcow2 4G

 #
# Монтируем диск и создаем раздел на нем..
qemu-nbd --connect=/dev/nbd0 /mnt/ramdisk/disk1.qcow2
mkfs.fat32 /dev/nbd0

В настоящее время свирепствует дезинформация, связанная с так называемой пандемией — заражением вирусом covid-19. Я не являюсь специалистом по распространению вирусов, не эпидемиолог и не врач. Я обычный человек, который закончил школу в СССР и имел твердую четверку по математике. Для того, чтобы понять, что пандемия это фейк, нужно обратиться к цифрам.

А цифры на сайте ВОЗ нам сообщают следующее: «каждый год от респираторных заболеваний, вызванных сезонным гриппом, умирает до 650 000 человек.» При этом смертность от обычного гриппа составляет 4%. Несложно подсчитать, что количество заболевших гриппом в допандемийном мире в год было 16 миллионов с четвертью. Эти люди спокойно болели дома, чихали, кашляли(иногда в маски и платки), наматывали сопли на рукав, но оставались в социуме.

Никто никаких эпидемий, пандемий не объявлял! В числе прочего, сообщалось, что: «Большинство людей выздоравливает от нее в течение недели без какой-либо медицинской помощи. Распространенные респираторные заболевания, которые связаны с сезонным гриппом и могут привести к смерти, включают в себя пневмонию и бронхит. » Сухие цифры статистики. Ни воплей, ни криков. Спокойно сообщали: «650 тысяч трупов в год».

Что мы имеем сейчас?

На момент написания этой статьи с момента возникновения заражения в Ухане прошло круглым счетом 3 месяца. То есть — четверть года. Смертность от гриппа covid-19 4.6 % в среднем в мире и менее 0.7 % в Германии (где медицина просто в шесть с половиной раз в среднем лучше, чем везде). Количество заболевших в мире — менее 670 000 человек.

При этом, даже исключая сезонность заболевания (считаю среднее арифметическое!), ВОЗ вполне допускал ранее за такой же период времени более 4 000 000 (четырех миллионов!) заболевших и 162 500 умерших, пандемию не объявляли! Конечно, смертность среди пожилых выше, но так было всегда, посмотрите статистику!

Что предлагаем мы в сложившейся ситуации? Готовы предложить вам аренду выделенного сервера в дата-центре Москвы. Аренда выделенного сервера (дедика) в дата-центре в России, Москва. Выделенные серверы Intel Xeon в аренду.

Собственно, чтобы два раза не вставать: у нас есть надежные серверы для вашего бизнеса. Арендуйте физический сервер для проектов с любой посещаемостью. Физические выделенные серверы. Мощные серверы Asus и Supermicro для сложных проектов с большой нагрузкой и особыми требованиями к надежности. Все серверы имеют доступ в IPMI и безлимитный трафик.

Всем рекомендую сохранять спокойствие, не поддаваться паническим атакам, меньше читать и смотреть новости. Не следует отменять вклады, покупать валюту и скупать продукты в прок. Не стоит вступать в конфликт с представителями власти — они на работе (а работа у них собачья) и могут не проявить сдержанность.

По-возможности нужно следовать старым советским догмам: проветривать помещение, больше находиться на свежем воздухе и на солнце — ультрафиолет губит любые вирусы, в том числе фейковые!

Всё будет хорошо, это обычный вирус гриппа, таких в год бывают десятки!

Начиная с 9 версии debian и c 15.10 ubuntu systemd переименовывает сетевые интерфейсы в корявые имена, понятные только разработчикам.

Понятно, что если ОС установлена на локальном компьютере, то можно посмотреть имя интерфейса и произвести настройку. Но если речь идет о удаленном сервере, то приходится идти на различные ухищрения. Но мне проще оставить имена, так как было раньше. Тема подробно разжевана в интернете по запросу «How can I show the old eth0 names and also rename network interfaces in debian 9 stretch?»

по сути нужно переконфигурировать загрузчик grub с опциями, возвращающими человеческие имена интерфейсов.

#
# редактируем файл опций загрузчика:
#
nano /etc/default/grub
# находим строку GRUB_CMDLINE_LINUX=""
# меняем ее содержимое на GRUB_CMDLINE_LINUX="net.ifnames=0 biosdevname=0"
#
# создаем новый конфиг загрузчика:
grub-mkconfig -o /boot/grub/grub.cfg

После перезагрузки наблюдаем привычные имена интерфейсов на сервере. Напоследок отмечу еще разок, что всё сказанное справедливо и для ubuntu

Довольно часто для установки различных операционных систем используем загрузку выделенного сервера в режим rescue, используя диcтрибутив grml. При этом в отечественных датацентрах отчего то не предоставляется услуга загрузки из сети и даже получение сетевых настроек по DHCP. Поэтому приходится действовать так:

# Сразу после загрузки GRML, даем
ifconfig eth0 45.156.200.66/27
# или, через ip:
ip a add 45.156.200.66/27 dev eth0
ip route add default via 45.156.200.65
# и следом настраиваем resolv.conf
echo "nameserver 8.8.8.8" >> /etc/resolv.conf

После этих манипуляций появляется сеть, остается только скачать скрипт grml.sh и начинать установку ОС. Конечно же, можно воспользоваться штатной утилитой grml-network, которая в диалоговом режиме позволяет настроить сеть.

Оказывается, что формат PDF не всегда верно интерпретируют старинные принтеры типа Canon LBP-810, LBP-1120 и аналогичных. При попытке печатать страница «расползается» и текст становится не читаемым. Проблема решается конвертированием PDF в TIFF

На Fedore моментально используем Ghostscript и действуем так:

gs -r300 -o page-tiffg4.tif -sDEVICE=tiff24nc source.pdf

где:

-r — разрешение в DPI,

-sDEVICE=tiff24nc — глубина цвета, может быть tiff32nc или tiff4

-o новый файл

source.pdf исходный файл

При попытке восстановить БД из дампа MySQL получил ошибку

ERROR 1064 (42000) at line 22: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near ‘DEFAULT CHARACTER SET latin1 */’ at line 1

Конечно же, дамп был очень большой (свыше 20 GB) и руками вымарать строку не представлялось возможным: ни vi, ни nano такой файл не смогут «прожевать»

Пришлось использовать старый добрый sed

# Строка была такой
# CREATE DATABASE /*!32312 IF NOT EXISTS*/ `databasename` /*!40100 DEFAULT CHARACTER SET latin1 */;
# Чтобы удалить ее, даем команду
sed -i 's/CREATE DATABASE.*;/--/' ./tempo.sql

Правда, на этом проблема не была завершена. На исходном сервере БД не имела префикс, а на новом — требовалось его использовать. Поэтому пришлось так же заменить databasename на admin_databasename. При попытке восстановления из бекапа ошибка была такой:

ERROR 1044 (42000) at line 22: Access denied for user ‘admin_databasename’@’localhost’ to database ‘databasename’

# Меняем название БД в дампе.
sed -i 's/`databasename`/`admin_databasename`;/' ./tempo.sql

После этой несложной манипуляции дальнейшее восстановление БД из дампа с ключом —default-character-set=utf8 прошло без запинок.

# Восстановление базы из дампа
mysql -uadmin_databasename -p admin_databasename  --default-character-set=utf8  < tempo.sql

Напомню в очередной раз, что выделенные серверы выгодно заказывать в компании vps-server.ru