Настраиваем веб-сервер на базе Apache в Debian / Ubuntu Server - Записки IT специалиста

Настраиваем веб-сервер на базе Apache в Debian / Ubuntu Server – Записки IT специалиста

Введение

Любая работа с сервером после установки чаще всего начинается со стандартных обязательных действий, без которых либо не получится продвинуться дальше, либо будет неудобно работать. Например, вам в любом случае необходимо выполнить сетевые настройки, желательно обновить систему и установить часовой пояс.

Об этом я хочу рассказать в статье. Я буду делиться своим реальным опытом работы. Это не значит, что нужно делать так, как я. Я могу в чем-то ошибаться, что-то делать не так удобно, как можно было бы сделать. Это просто советы, которые кому-то помогут узнать что-то новое, а кто-то возможно поделится со мной чем-то новым для меня, либо укажет на мои ошибки.

Что это значит?

В ближайшие недели произойдет следующее:

  • я передам важные пакеты maintained-команде;
  • удалю себя из Uploaders пакетов, в которых есть другие сопровождающие;
  • пакеты, в которых я был единственным сопровождающим, станут «сиротами».


Я постараюсь и дальше поддерживать страницы

и сервис

, но высоко оценю любую помощью по этому направлению.

Если у вас возникнут вопросы или какие-то задачи, считайте, что я в бессрочном отпуске. Я постараюсь принимать участие в каких-то административных вопросах (например, передачи разрешений) и задачах, адресованных лично мне, но только если это не займет много времени.

Почему?

Когда я только присоединился к работе над Debian, я еще учился, то есть у меня было много свободного времени. Теперь, спустя пять лет работы фулл-тайм, я многому научился — как в плане того, как и что работает в крупных проектах по разработке программного обеспечения, так и в плане понимания своих личных предпочтений в компьютерных системах.

Каждый из следующих разделов будет посвящен вещам, причиняющим мне как разработчику боль. Список этот приводится в произвольном порядке. Некоторые из этих проблем влияют друг на друга, например — если бы изменения системы проводились качественнее, у нас был бы шанс на то, что пакеты будут легче обрабатываться машиной.

Debian — это болезненный опыт для разработчика


Большинство поднятых мной вопросов касаются опыта разработки Debian, но, как я недавно описал в своем посте

, опыт разработки

с использованием Debian

также оставляет желать лучшего.

Безопасный и шустрый веб-сервер на debian 7

Статья, находится в процессе написания, но я готов выслушать дельные советы и комментарии, а затем доплнить или поправить материал.

Прежде всего, данный материал ориентирован на новичков и тех, кто держит на одном VPS сразу несколько сайтов, при этом хочет иметь как безопасный, так и шустрый веб-сервер.

В качестве веб-сервера у нас будет выступать связка:

Apache 2.2 PHP 5.4.4 MySQL 5.5 NGINX 1.2.1 eAccelerator memcached vsftpd 3.0.2 exim.

Все это чудо будет крутиться на Debian 7.

Начнем.

Итак, прежде всего после установки ОС, выполняем:

apt-get update
apt-get dist-upgrade

Затем одной командой ставим весь необходимый софт:

apt-get install htop atop vsftpd exim4-base exim4-daemon-light mailutils rcconf apache2 apache2-mpm-itk nginx mysql-server-5.5 mysql-client-5.5 php5 php5-dev memcached libmysqlclient-dev apache2-utils libexpat1 ssl-cert libapache2-mod-php5 libapache2-mod-ruby php5-curl php5-gd php5-intl php-pear php5-imagick php5-imap php5-mcrypt php5-memcache php5-common php5-ming php5-mysql php5-pspell php5-recode php5-snmp php5-sqlite php5-tidy php5-xmlrpc php5-xsl make automake checkinstall gcc gzip libreadline-dev libssl-dev libncurses5-dev zlib1g-dev

В процессе установки система попросит вас придумать и ввести пароль для пользователя root БД MySQL, вводим.
После полной установки софта, приступаем к настройке. Все сайты у нас будут лежать в директории /home/директория_пользователя/директория_сайта, но вы можете разместить их в любой удобной для вас директории. В директории сайта у нас будут 3 поддиректории: tmp (для временных файлов и файлов сессий), logs (логи сайта), public_html (директория сайта).

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

useradd dapf -b /home -m -U -s /bin/false

Устанавливаем пароль пользователя dapf:

passwd dapf 

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

mkdir -p -m 755 /home/dapf/dapf.ru/public_html
mkdir -p -m 777 /home/dapf/dapf.ru/logs
mkdir -p -m 777 /home/dapf/dapf.ru/tmp
chmod 755 /home
chmod 755 /home/dapf
chmod  t /home/dapf/dapf.ru/logs
chmod  t /home/dapf/dapf.ru/tmp
chown -R dapf:dapf /home/dapf

Запретим консоль пользователю www-data:

usermod -s /bin/false www-data

Теперь приступим к настройке Apache.
Включаем необходимые нам модули:

a2enmod ssl
a2enmod rewrite
a2enmod suexec
a2enmod include

Правим конфиг портов в файле /etc/apache2/ports.conf:

nano /etc/apache2/ports.conf

Необходимо заменить 80 порт на 81 (т.к. на 80м у нас будет nginx):

NameVirtualHost *:81
Listen 81

Поскольку у нас VPS слабенький (256 мб ОЗУ), то нам необходимо настроить /etc/apache2/apache2.conf

nano /etc/apache2/apache2.conf

Устанавливаем следующие значения:

KeepAlive Off
StartServers 1
MinSpareServers 3
MaxSpareServers 6
ServerLimit 24
MaxClients 24
MaxRequestsPerChild 3000

Теперь создадим новый VirtualHost (сайт):

nano /etc/apache2/sites-available/dapf.ru
<VirtualHost *:81>
ServerName www.dapf.ru
ServerAlias dapf.ru
ServerAdmin support@dapf.ru
DocumentRoot "/home/dapf/dapf.ru/public_html"
  <Directory />
  Options FollowSymLinks
  AllowOverride None
  </Directory>
  <Directory /home/dapf/dapf.ru/public_html/>
  Options Indexes FollowSymLinks MultiViews
  AllowOverride All
  Order allow,deny
  allow from all
  </Directory>
  ErrorLog /home/dapf/dapf.ru/logs/errors.log
  LogLevel warn
  CustomLog /home/dapf/dapf.ru/logs/access.log combined
  AssignUserId www-data dapf
  php_admin_value open_basedir "/home/dapf/:."
  php_admin_value upload_tmp_dir "/home/dapf/dapf.ru/tmp"
  php_admin_value session.save_path "/home/dapf/dapf.ru/tmp"
</VirtualHost>

Благодаря apache2-mpm-itk мы имеем возможность использовать в конфигах виртуалхоста директиву AssignUserId www-data dapf, которая позволяет запретить web-шеллу, править файлы нашего проекта, кроме тех, на которых стоят права o w. Т.е. apache сможет спокойно прочитать php-файл, выполнить его и отдать в браузер, но не сможет внести изменения в его содержимое, что создаст определенные проблемы для хэкеров. Если хотите разрешить апачу править файлы, то используйте вместо www-data dapf, значение dapf dapf. Директивы open_basedir, upload_tmp_dir, session.save_path исключают получение сессий с соседнего сайта и переходы выше пользовательской директории.

Включаем сайт:

a2ensite dapf.ru

И перезагружаем апач:

service apache2 restart

С апачем закончили, теперь настроим nginx.
Для начала настроим gzip сжатие, назначим пользователя www-data и установим 1 ядро процессора.

nano /etc/nginx/nginx.conf
user www-data;
worker_processes 1;
pid /var/run/nginx.pid;
error_log /var/log/nginx/error.log;
events {
  worker_connections 768;
  # multi_accept on;
}
http {
  ##
  # Basic Settings
  ##
  sendfile on;
  tcp_nopush on;
  tcp_nodelay on;
  keepalive_timeout 65;
  types_hash_max_size 2048;
  # server_tokens off;
  # server_names_hash_bucket_size 64;
  # server_name_in_redirect off;
  include /etc/nginx/mime.types;
  default_type application/octet-stream;
  ##
  # Logging Settings
  ##
  access_log /var/log/nginx/access.log;
  error_log /var/log/nginx/error.log;
  ##
  # Gzip Settings
  ##
  gzip on;
  gzip_disable "msie6";
  # gzip_vary on;
  gzip_proxied any;
  gzip_comp_level 7; #Level Compress
  gzip_buffers 16 8k;
  gzip_http_version 1.1;
  gzip_types text/plain text/css application/json application/x-javascri$
  ##
  # Virtual Host Configs
  ##
  include /etc/nginx/conf.d/*.conf;
  include /etc/nginx/sites-enabled/*;
}

После создадим новый конфиг нашего виртуалхоста:

nano /etc/nginx/sites-enabled/dapf.ru
server {
listen 80;
server_name dapf.ru www.dapf.ru;
access_log /var/log/nginx.access_log;
location ~* .(jpg|jpeg|gif|png|ico|css|zip|tgz|gz|rar|bz2|doc|xls|exe|pdf|ppt|txt|tar|mid|midi|wav|bmp|rtf|js|swf|flv|html|htm|mp3|docx|xlsx)$ {
root /home/dapf/dapf.ru/public_html/;
error_page 404 = @fallback;
index index.html index.php;
access_log off;
expires 30d;
}
location ~ /.ht { deny all; }
location / {
proxy_pass http://127.0.0.1:81/;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-for $remote_addr;
proxy_set_header Host $host;
proxy_connect_timeout 60;
proxy_send_timeout 90;
proxy_read_timeout 90;
proxy_redirect off;
proxy_set_header Connection close;
proxy_pass_header Content-Type;
proxy_pass_header Content-Disposition;
proxy_pass_header Content-Length;
}
location @fallback {
  proxy_pass http://127.0.0.1:81;
  proxy_set_header Host $host;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  proxy_set_header X-Forwarded-Proto $scheme;
  proxy_set_header X-Real-IP $remote_addr;
  }
}  

Теперь за всю динамику отвечает апач, а за статику nginx, при появлении ошибки 404, которая может возникнуть при использования mod_rewrite(ЧПУ), будет вызываться функция @fallback, которая перенаправит запрос на апач для проверки.

Перезагружаем nginx: service nginx restart

Для настройки FTP правим файл конфига vsftpd

nano /etc/vsftpd.conf

Удаляем всё и вставляем следующие настройки:

listen=YES
anonymous_enable=NO
local_enable=YES
write_enable=YES
pasv_min_port=50000
pasv_max_port=60000
dirmessage_enable=YES
xferlog_enable=YES
file_open_mode=0644
local_umask=022
connect_from_port_20=YES
ascii_upload_enable=YES
ascii_download_enable=YES
ftpd_banner=Welcome to our FTP service.
chroot_local_user=YES
allow_writeable_chroot=YES
secure_chroot_dir=/var/run/vsftpd
pam_service_name=vsftpd
rsa_cert_file=/etc/ssl/certs/vsftpd.pem

Это позволит запретить вход анонимным пользователям, разрешить использование старых FTP клиентов, а также ограничить перемещение пользователей только их домашним каталогом.

Затем необходимо поправить файл /etc/pam.d/vsftpd, чтобы включить возможность авторизации FTP пользователям, не имеющим доступ к консоли.

nano /etc/pam.d/vsftpd

Находим и комментируем строку: auth required pam_shells.so

#auth  required  pam_shells.so

Перезагружаем vsftpd и пробуем войти:

service vsftpd restart

Если у вас возникла ошибка: 500 OOPS: vsftpd: refusing to run with writable root inside chroot(), не расстраиваемся — это баг vsftpd, и решается он простым обновлением, для этого выполняем:

echo "deb http://ftp.us.debian.org/debian jessie main contrib non-free" >> /etc/apt/sources.list
aptitude update
aptitude upgrade vsftpd
echo "allow_writeable_chroot=YES" >> /etc/vsftpd.conf
service vsftpd restart

Возможно, вам придется заново поправить конфиги vsftpd, но после перезапуска сервиса всё будет работать нормально.

Настраиваем MySQL.

nano /etc/mysql/my.cnf

Устанавливаем следующие значения директив:

key_buffer = 16K
max_allowed_packet = 1M
thread_stack = 64K
table_cache = 4
sort_buffer = 64K
net_buffer_length = 2K

Если вы не используете таблицы InnoDB, можно добавить директиву skip-innodb

Далее создадим пользователя и его БД, выполнив команду:

echo "CREATE USER 'база_данных'@'localhost' IDENTIFIED BY 'пароль_пользователя'; GRANT USAGE ON * . * TO 'база_данных'@'localhost' IDENTIFIED BY 'пароль_пользователя' WITH MAX_QUERIES_PER_HOUR 0 MAX_CONNECTIONS_PER_HOUR 0 MAX_UPDATES_PER_HOUR 0 MAX_USER_CONNECTIONS 0; CREATE DATABASE IF NOT EXISTS база_данных DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci; ; GRANT ALL PRIVILEGES ON база_данных . * TO 'база_данных'@'localhost';" | mysql --user=root --password=пароль_рута_мускула mysql

Значения база_данных, пароль_пользователя, пароль_рута_мускула указываем свои.

Основную часть работы мы закончили, теперь необходимо настроить PHP eAccelerator exim.

Начнем с настройки exim, выполняем:

dpkg-reconfigure exim4-config

Выбираем ОК, потом internet site; mail is sent and received directly using SMTP, указываете ваш System mail name (у меня это dapf.ru), IP-addresses to listen on for incoming SMTP connections можно оставить просто 127.0.0.1, далее по вкусу, пока не дойдете до Root and postmaster mail recipient, там указываем ваш email, на который будут возвращаться письма.

Выполняем для проверки:

echo "test" | mail -s Test ваш@email.com

Если письмо пришло, значит все отлично, если нет, то возвращаемся и перенастраиваем exim.
Теперь установим eAccelerator.

Качаем последнюю на данный момент версию и распаковываем:

wget https://codeload.github.com/eaccelerator/eaccelerator/legacy.tar.gz/master -O ea.tar.gz
tar xvfz ea.tar.gz

Переходим в директорию с исходниками eaccelerator(у меня это eaccelerator-eaccelerator-42067ac) и устанавливаем:

cd eaccelerator-eaccelerator-42067ac
phpize
./configure
make
make install

Создадим директорию для кеша eAccelerator

mkdir -p /var/cache/eaccelerator
chmod 0777 /var/cache/eaccelerator

Редактируем файл php.ini

nano /etc/php5/apache2/php.ini

Здесь нам необходимо добавить настройки eAccelerator, sendmail, в качестве которого у нас exim, настройки безопасности и т.д.
Добавляем перед [ PHP ] настройки для eAccelerator

; eAccelerator configuration
; Note that eAccelerator may also be installed as a PHP extension or as a zend_extension
; If you are using a thread safe build of PHP you must use
; zend_extension_ts instead of zend_extension
extension  = "eaccelerator.so"
eaccelerator.shm_size  = "16"
eaccelerator.cache_dir  = "/var/cache/eaccelerator"
eaccelerator.enable  = "1"
eaccelerator.optimizer  = "1"
eaccelerator.check_mtime  = "1"
eaccelerator.debug  = "0"
eaccelerator.filter  = ""
eaccelerator.shm_max  = "0"
eaccelerator.shm_ttl  = "0"
eaccelerator.shm_prune_period  = "0"
eaccelerator.shm_only  = "0"
eaccelerator.compress  = "1"
eaccelerator.compress_level  = "9"
eaccelerator.allowed_admin_path = "/var/www/eaccelerator"

Теперь раскомментируем sendmail_path и укажем путь до exim

sendmail_path = /usr/sbin/exim -t

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

;Отключаем вывод ошибок и включаем их запись в файл
display_errors =Off
log_errors=On
;Отключаем опасные функции
disable_functions = exec,ini_get,ini_get_all,parse_ini_file,passthru,php_uname,popen,proc_open,shell_exec,show_source,system,dl, show_source, readfile, popen, cwd,getcwd
;По вкусу можно отключить и функции: diskfreespace, disk_free_space, disk_total_space, eval, fileperms, fopen, opendir, phpinfo, phpversion, posix_getpwuid, posix_getgrgid, posix_uname, но не рекомендуется.
;Прочие настройки
error_reporting = E_ALL & ~ E_NOTICE

Остальные настройки PHP делайте по вашему желанию, на эту тему в сети имеется куча мануалов.

Сейчас ищут техподдержку:  Официальный сайт УФМС России по Московской области - Официальный сайт УФМС России

Настройку SSH я рассматривать не буду, а остановлюсь на фаерволе, т.к. в Debian по умолчанию разрешены все подключения.

Создаем файл my.iptables.rules

nano /etc/my.iptables.rules
*filter
-A INPUT -i lo -j ACCEPT
-AINPUT -d 127.0.0.0/8 -jREJECT
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A OUTPUT -j ACCEPT
-A INPUT -p tcp --dport 80 -j ACCEPT
-A INPUT -p tcp --dport 443 -j ACCEPT
-A INPUT -p tcp --dport 20 -j ACCEPT
-A INPUT -p tcp --dport 21 -j ACCEPT
-A INPUT -p tcp --dport 50000 -j ACCEPT
-A INPUT -p tcp --dport 60000 -j ACCEPT
-A INPUT -p tcp -m state --state NEW --dport 22 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables denied: " --log-level 7
-A INPUT -j REJECT
-A FORWARD -j REJECT
COMMIT

Активируем и сохраняем правила:

iptables-restore < /etc/my.iptables.rules
iptables-save > /etc/iptables.rules

Проверяем командой iptables –L

Прописываем загрузку в файле /etc/network/interfaces

nano /etc/network/interfaces

После iface lo inet loopback добавляем

pre-up iptables-restore < /etc/iptables.rules

Сохраняем и перезагружаем VPS.

Как настроить сайт на debian без домена?

Доброго времени!
Ребят есть маленькая локалка, где примерно 10 компов. На одном стоит debian со всеми настройками для сайта.
Машина с дебиан полностью настроена, работает. Есть подключение через внешний и внутренний IP.
Есть поддомен к которому приписан IP компьютера как DNS сервер.
Вопрос состоит в том как настроить сам сайт чтобы открывался по IP?
то есть вместо It works! чтобы открывалась индексная страница сайта (/var/www/sitename)
В какую сторону копать?

Кароч mysql восстанавливаем из бэкапа, он работает некоторое время работает потом падает

Машинам сложно работать с debian

Хотя очевидно, что с пакетами Debian можно работать программно, этот опыт сложно назвать приятным. Все кажется медленным и громоздким. Я выбрал три небольших примера, чтобы проиллюстрировать мою позицию по этому вопросу.

debiman нуждается в помощи от piuparts в проведении анализа альтернативного механизма каждого пакета по отображению страниц документации, например, PSQL(1). Это потребовалось, так как сценарии модифицируют альтернативную базу через вызов shell-скриптов. Но без фактической установки пакета вы не узнаете, какие изменения он вносит.

pk4 должен поддерживать свой собственный кеш для поиска метаданных пакета на основе его имени. Другие инструменты анализируют базу данных apt с нуля при каждом вызове. Правильный формат базы данных или, по крайней мере, двоичный формат обмена будет иметь большое значение для этого процесса.

Debian Code Search хочет как можно быстрее получать новые пакеты. Раньше использовался инстанс fedmsg, но его больше не существует. Неясно, откуда получать уведомления о новых пакетах и ​​где лучше всего их получать.

Настройка firewall (iptables) в debian

В качестве firewall в Debian по-умолчанию используется iptables, его и будем настраивать. Изначально фаервол полностью открыт и пропускает весь трафик. Проверить список правил iptables можно следующей командой:

# iptables -L -v -n

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Обращаю пристальное внимание на то, что настраивать firewall без прямого доступа к консоли сервера не следует. Особенно, если вы не очень разбираетесь в этом и копируете команды с сайта. Шанс ошибиться очень высок. Вы просто потеряете удаленный доступ к серверу.

Создадим файл с правилами iptables:

# mcedit /etc/iptables.sh

Очень подробно вопрос настройки iptables я рассмотрел отдельно, рекомендую ознакомиться. Хотя в примере другая ОС linux, принципиальной разницы нет, настройки iptables абсолютно одинаковые, так как правила одни и те же.

Добавляем набор простых правил для базовой настройки. Все необходимое вы потом сможете сами открыть или закрыть по аналогии с существующими правилами:

Настройка ssh

Теперь внесем некоторые изменения в настройки сервера ssh. Я рекомендую его запускать на нестандартном порту для исключения лишних общений с ботами, которые регулярно сканируют интернет и подбирают пароли пользователей по словарям.

Существует расхожее мнение, что менять порт ssh это наивность, а не защита. Надо просто настроить сертификаты, fail2ban или еще каким-то образом защитить ssh порт, к примеру, с помощью ограничений iptables, и т.д. Тем не менее, я все же рекомендую порт сменить на нестандартный.

По-умолчанию в Debian, впрочем как и в любом другом дистрибутиве Linux, ssh сервер работает на 22 порту. Изменим этот порт, к примеру, на 23331. Так же я еще изменяю конфигурацию для разрешения подключения по ssh пользователя root с использованием пароля. В Debian из коробки пользователь root по ssh паролем авторизовываться не может. Изменим и это. Открываем файл настроек:

# nano /etc/ssh/sshd_config

И изменяем там следующие строки. Приводим их к виду:

Port 23331
PermitRootLogin yes

Сохраняем изменения и перезапускаем сервер ssh следующей командой:

# service sshd restart

Проверяем изменения:

# netstat -tulnp | grep ssh

tcp 0 0 0.0.0.0:23331 0.0.0.0:* LISTEN 925/sshd
tcp6 0 0 :::23331 :::* LISTEN 925/sshd

Все в порядке, сервер слушает 23331 порт. Теперь новое подключение будет осуществлено только по порту 23331. При этом, после перезапуска ssh, старое подключение не будет разорвано.

Я знаю, что многие возражают против подключения рутом к серверу. Якобы это небезопасно и т.д. и т.п. Мне эти доводы кажутся не убедительными. Не понимаю, в чем может быть проблема, если у меня нормальный сложный пароль на root, который не получится подобрать или сбрутить.

Отдельно тему подключения к серверу под root я рассмотрел в статье про sudo. Кому интересно, переходите в нее и делитесь своим мнением на этот счет.

Настройка и обновление времени в debian

Теперь проверим установленный часовой пояс, время и включим автоматическую синхронизацию времени с удаленного сервера. Очень подробно этот вопрос я рассмотрел в отдельной статье – настройка времени в Debian.

Узнать дату, время, часовой пояс можно командой date:

# date

Mon 12 Aug 2021 02:29:03 PM MSK

Если все указано верно, то менять ничего не нужно. Если же у вас неправильное время или указан часовой пояс не соответствующий вашему, то настроить это можно следующим образом. Сначала обновим часовые пояса:

# apt install tzdata

Теперь выберем правильный часовой пояс с помощью команды:

# dpkg-reconfigure tzdata

Выбирая соответствующие пункты визарда, указываете свой часовой пояс.

Дальше синхронизируем время с сервером времени в интернете. Для разовой или ручной синхронизации понадобится отдельная утилита. Установим ntpdate на сервер:

# apt install ntpdate

И синхронизируем время:

# ntpdate-debian

12 Aug 14:30:21 ntpdate[8688]: adjust time server 89.109.251.21 offset 0.004529 sec

Если получаете ошибку:

12 Aug 14:30:21 ntpdate[8688]: the NTP socket is in use, exiting

Значит у вас уже работает служба ntp. Ее нужно остановить и обновить время вручную. Хотя если она работает, то у вас и так должно быть все в порядке.

Для того, чтобы время автоматически синхронизировалось без вашего участия с определенной периодичностью, используется инструмент ntp. Установим его:

# apt install ntp

После установки он сам запустится и будет автоматически синхронизировать часы сервера. Проверим, запустился ли сервис ntpd:

# netstat -tulnp | grep ntp

udp        0      0 10.20.1.16:123          0.0.0.0:*                           8855/ntpd           
udp        0      0 127.0.0.1:123           0.0.0.0:*                           8855/ntpd           
udp        0      0 0.0.0.0:123             0.0.0.0:*                           8855/ntpd           
udp6       0      0 fe80::cce1:23ff:fe4:123 :::*                                8855/ntpd           
udp6       0      0 ::1:123                 :::*                                8855/ntpd           
udp6       0      0 :::123                  :::*                                8855/ntpd

Настройка логов cron

По-умолчанию, в Debian нет отдельного лог файла для событий cron, они все сыпятся в общий лог /var/log/syslog. Лично мне это не очень нравится, я предпочитаю выводить эти события в отдельный файл. Об этом я написал отдельно – вывести логи cron в отдельный файл.

Обновление системы, отличие apt upgrade от dist-upgrade и full-upgrade

Сеть настроили, теперь можно обновить систему и пакеты. В Debian это делается достаточно просто. Воспользуемся несколькими командами. Сначала обновим локальный индекс пакетов до последних изменений в репозиториях:

# apt update

Посмотреть список пакетов, готовых к обновлению, можно с помощью команды:

# apt list --upgradable

Теперь выполним простое обновление всех пакетов системы:

# apt upgrade

Ключ upgrade выполняет только обновление одной версии пакета на другую, более свежую. Он не будет устанавливать или удалять пакеты, даже если это необходимо для обновления других. Это наиболее безопасный и надежный вариант обновления, но он может обновить не все. Например, с ее помощью не обновить ядро до более свежей версии.

Ключ dist-upgrade или full-upgrade (это одно и то же) в дополнение к upgrade обрабатывает все изменения зависимостей для новых пакетов и во время работы может удалять ненужные и ставить необходимые пакеты для обновления. Вот выдержка из документации по поводу этих двух ключей.

Так что после обычного обновления, делаем еще full-upgrade.

# apt full-upgrade
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Calculating upgrade... Done
The following packages were automatically installed and are no longer required:
  dh-python guile-2.0-libs libbind9-140 libdns162 libicu57 libisc160 libisccc140 libisccfg140 liblvm2app2.2 liblvm2cmd2.02 liblwres141 libperl5.24
  libpython3.5-minimal libpython3.5-stdlib linux-image-4.9.0-3-amd64 python3-distutils python3-lib2to3 python3.5 python3.5-minimal rename sgml-base tcpd
  xml-core
Use 'apt autoremove' to remove them.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

Мне предлагается удалить старые пакеты, которые больше уже не нужны. Это зависимости от старых версий софта, который уже обновился и получил новые пакеты из зависимостей, а эти ему больше не нужны. Очистим их командой:

# apt autoremove

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

Сейчас ищут техподдержку:  Условия и положения | Tommy Hilfiger®

На этом обновление системы закончено. Если вы хотите обновить версию релиза, например Debian 9 обновить до Debian 10 Buster, то читайте отдельный материал.

Процесс изменений в debian

Последние несколько лет моя текущая команда работала над различными реорганизациями по всей кодовой базе (затрагивая тысячи проектов), поэтому мы получили множество ценных уроков, как эффективно эти изменения вносить. Меня раздражает то, что Debian во всех смыслах работает практически противоположным образом. Я ценю то, что каждый проект отличается, но я думаю, что многие далее перечисленные мою пункты применимы к Debian целиком.

В Debian разработка пакетов направляется в нужное русло с помощью документа, который называется «Debian Policy», либо же его программным вариантом «Lintian».

Несмотря на то, что lint очень удобен для получения быстрого прямого или локального/автономного фидбека, еще лучше вообще не требовать пользоваться таким инструментом. Например, команда C , которая вводит новый флаг защиты для всех пакетов, должна быть в состоянии сделать свою работу прозрачной и для меня (судя по профилю GitHub, основным языком Михаэля является Go, — прим. пер.).

Вместо этого сейчас все пакеты делаются «грязно» (ориг. — lint-unclean): все сопровождающие должны прочитать, что это за новая вещь, как она может сломаться, влияет ли она на их работу вообще и если да, то как именно. Потом надо вручную запустить некоторые тесты и, наконец, отказаться от изменений. Все это — множество накладных и выполняемых вручную механических операций между пакетами.

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

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

В Debian отсутствуют инструменты для внесения крупных изменений: программно сложно работать с раздробленными пакетами и репозиториями (об этом детальнее в разделе ниже). Наиболее близким событием к дефолтной «отправке изменения на ревью» является процесс открытия баг-репорта с прикрепленным к нему патчем.

Мне казалось, что существующий процесс принятия баг-фикса слишком сложен, и я начал работать над мерж-ботом, но интерес к нему проявил только Гвидо и никто больше (по всей видимости, автор говорит о Гвидо agx Гюнтере, еще одном Debian-разработчике, — прим. пер.).

Если выражаться литературно, то реакция на пуши и, соответственно, получение обратной связи проходят медленно. Там просто нет сроков. Иногда я получаю электронные письма, уведомляющие меня о том, что отправленный мною несколько лет назад (!!!) патч наконец-то смержили. Это растягивает недельные проекты на много лет, что для меня является мощным демотиватором.

Любопытно отметить, но практика черепашьей онлайн-активности проецируется и на офлайн-культуру, а я не хочу обсуждать достоинства systemd спустя 10 лет после того, как впервые услышал о нем.

Ну и наконец, любые изменения могут быть застопорены несогласными, которые в итоге отказываются идти на сотрудничество. Мой каноничный пример подобной ситуации — rsync. Куратор отказался от моих патчей, добавляющих в пакет поддержку debhelper, исключительно из собственных убеждений.

Предоставление такой степени личной свободы отдельным сопровождающим мешает всем нам, участникам проекта, повысить уровень абстракции сборки Debian, что, в свою очередь, усложняет инструментарий разработки.

Как бы все это выглядело в идеальном мире?

  1. Как проект, мы должны стремиться к унификации. Ведь унификация не исключает экспериментов, она просто меняет текущий компромисс между более простыми экспериментами и более сложной автоматизацией на компромисс между более сложными экспериментами и более простой автоматизацией.
  2. Наша культура разработки должна уйти от парадигмы «этот пакет — мое хозяйство, да как ты смеешь к нему прикасаться», к общему чувству сопричастности, при котором любой участник может легко вносить или проверять изменения, даже без вовлечения конкретных кураторов-сопровождающих.

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

Сложный билд-стек


Тут можно просто почитать мой пост

. Меня действительно беспокоит тот факт, что рост числа инструментов не считается проблемой.

У меня есть больше идей

Статья получилась достаточно объемной, но я надеюсь, вы получили приблизительное представление о моей мотивации.

Хотя выше я описал ряд конкретных недостатков, последний гвоздь в крышку гроба — это отсутствие позитивного прогноза на будущее. У меня есть другие идеи, которые кажутся мне действительно убедительными, но, исходя из того, как продвигались мои предыдущие проекты, я не думаю, что смогу реализовать что-либо из них в рамках проекта Debian.

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

Ну и наконец, я надеюсь, что этот пост вдохновит кого-нибудь, в идеале — группу людей, на то, чтобы сделать жизнь разработчиков Debian лучше.

Указываем сетевые параметры

Итак, у нас в наличии только что установленная система. Узнать или проверить ее версию можно командами:

# uname -a
Linux debian10 4.19.0-5-amd64 #1 SMP Debian 4.19.37-5 (2021-06-19) x86_64 GNU/Linux

# lsb_release -a
No LSB modules are available.
Distributor ID:	Debian
Description:	Debian GNU/Linux 10 (buster)
Release:	10
Codename:	buster

Очень подробно про настройку сети в Debian я написал в отдельной статье. Рекомендую с ней ознакомиться. Здесь же кратко выполним основное. Для настройки сети, необходимо отредактировать файл /etc/network/interfaces. Сделаем это:

# nano /etc/network/interfaces

Для получения IP адреса по dhcp достаточно будет следующего содержания:

allow-hotplug eth0
iface eth0 inet dhcp

Если у вас статический адрес, то его настроить можно следующими параметрами в файле:

allow-hotplug eth0
iface eth0 inet static
address 192.168.1.24
netmask 255.255.255.0
gateway 192.168.1.1
dns-nameservers 192.168.1.1

Сохраняем файл. Теперь нужно выполнить перезапуск сети. В Debian это делается командой:

# systemctl restart networking.service

В системном логе /var/log/syslog при этом будут записи:

debian10 systemd[1]: Stopping Raise network interfaces...
debian10 systemd[1]: networking.service: Succeeded.
debian10 systemd[1]: Stopped Raise network interfaces.
debian10 systemd[1]: Starting Raise network interfaces...
debian10 systemd[1]: Started Raise network interfaces.

Будьте аккуратны при настройке и перезапуске сети, если подключаетесь к серверу удаленно. Обязательно должен быть доступ к консоли на случай, если где-то ошибетесь и потеряете доступ к серверу.

К сетевым настройкам я отношу установку пакета net-tools, в состав которого входят старые и привычные утилиты для работы с сетью – ifconfig, netstat, route и другие. В современных дистрибутивах их заменили одной командой ip, но лично мне вывод некоторых старых команд, конкретно, netstat, нравится больше, поэтому я иногда ими тоже пользуюсь.

# apt install net-tools

На этом настройка сети закончена.

Установка apache

Установка веб-сервера предельно проста:

apt-get install apache2

Для проверки его работы наберите в браузере IP-адрес сервера, и вы увидите стандартную страницу заглушку:

LAMP-Debian-Ubuntu-001.jpg

Настройки сервера содержатся в /etc/apache2/apache2.conf, к которому подключаются дополнительные файлы из директорий mods-enabled и sites-enabled. При этом никто не мешает вам внести все указанные настройки непосредственно в apache2.conf – все будет работать, но это резко снижает удобство администрирования, так как требует постоянной правки основного файла конфигурации, в то время как настройки во внешних файлах легко включаются и отключаются при помощи специальных инструментов.

С этой целью каталоги mods-enabled и sites-enabled не содержат файлов конфигурации, а только символические ссылки на директории mods-available и sites-available, где следует располагать сами файлы. Как понятно из названий, в данных каталогах находятся настройки модулей и виртуальных хостов. Если с модулями дело приходится иметь редко, то управлять таким образом виртуальными хостами, т.е. сайтами, очень удобно.

Установка mysql

СУБД MySQL – третий необходимый компонент полноценного веб-сервера, основное назначение базы данных – хранение информации сайта, как пользовательской, так и служебной. При этом по важности СУБД превосходит все остальные компоненты, так как потеря базы данных равносильна потере всей информации вашего ресурса.

Установим сервер баз данных и модуль PHP для работы с ним:

apt-get install mysql-server php5-mysql

Важно! В свежих выпусках Debian (и его производных) вместо пакета mysql-server следует установить mariadb-server, который полностью совместим с MySQL.

В процессе установки вам будет предложено ввести пароль для суперпользователя MySQL (root), которого не следует путать с суперпользователем системы.

Установка php

Если веб-сервер был нужен вам для размещения статического содержимого или сторонних веб-приложений, например, публикации баз 1С:Предприятия, то дальше можно не читать. Но если вы собираетесь создать сайт на основе популярных CMS – вам потребуется поддержка скриптового языка PHP, на базе которого разработаны большинство современных “движков”.

Важно! В современных дистрибутивах используется более новая версия PHP7, чтобы работать с новой версией языка вместо php5 в приведенных ниже командах следует указывать php7.x или просто php, например, вместо php5-imagick нужно набрать php7.0-imagick или php-imagick.

Выполним команду:

apt-get install php5

Будет установлен сам интерпретатор и необходимые для работы с веб-сервером модули. Модули позволяют гибко изменять функциональность PHP, управление модулями осуществляется аналогично Apache, когда конфигурации модулей располагаются в одной директории, а для их подключения делается символьная ссылка в другую.

По умолчанию PHP устанавливается с базовым набором модулей, который удовлетворяет большинство потребностей, однако применяемая вами CMS может требовать дополнительных модулей, которые нужно будет установить отдельно.

Сейчас ищут техподдержку:  LocalStorage is not defined? — Хабр Q&A

Например, для работы с графикой вам потребуется поддержка графической библиотеки GD2, поэтому установим соответствующий модуль:

apt-get install php5-gd

После чего не забудьте перезапустить веб-сервер:

service apache2 reload

Кстати, GD2, на наш взгляд не самый лучший выбор, в актив библиотеки можно записать низкое потребление ресурсов и высокую скорость работы, но по качеству работы с изображениями она уступает альтернативной утилите imagemagick, иногда значительно.

Установим утилиту и модуль PHP для нее:

apt-get install imagemagick php5-imagick

Для проверки работы PHP создадим в корневой директории сайта специальный скрипт:

Установка и настройка screen

Я привык в своей работе пользоваться консольной утилитой screen. Изначально она задумывалась как инструмент, который позволяет запустить что-то удаленно в консоли, отключиться от сервера и при этом все, что выполняется в консоли продолжит свою работу. Вы сможете спокойно вернуться в ту же сессию и продолжить работу.

Первое время я именно так и использовал эту утилиту. Редко ее запускал, если не забывал, когда выполнялся какой-то длительный процесс, который жалко было прервать из-за случайного обрыва связи или необходимости отключить ноутбук от сети и куда-то переместиться.

Позже я решил подробнее ознакомиться с этим инструментом и обнаружил, что там есть несколько удобных моментов, которые можно использовать в ежедневной работе. Вот как использую утилиту screen я. При подключении к серверу у меня запускается screen с тремя окнами 1, 2, 3.

Первое окно автоматически переходит в каталог /, второе в /etc, третье в /var/log. Я осмысленно назвал эти окна: Main, etc, logs соответственно. Внизу находится строка состояния, в которой отображен список всех открытых окон и подсвечено активное окно.

С помощью горячих клавиш я очень быстро переключаюсь между окнами в случае необходимости. Вот как выглядит мое рабочее окно ssh подключения:

Переключаюсь между окнами с помощью стандартных горячих клавиш screen: ctrl a 1,  ctrl a 2, ctrl a 3. Я специально изменил нумерацию, чтобы она начиналась не с 0 по-дефолту, а с 1. Так удобнее на клавиатуре переключать окна. Кнопка 0 находится слишком далеко от 1 и 2.

Чтобы настроить такую же работу screen, как у меня, достаточно выполнить несколько простых действий. Сначала устанавливаем screen:

# apt install screen

Создаем в каталоге /root конфигурационный файл .screenrc следующего содержания:

# mcedit /root/.screenrc
#Выводим строку состояния
hardstatus alwayslastline "%-Lw%{= BW}P>%n%f* %t%{-}% Lw%<"

# Добавляем некоторые настройки
startup_message off
defscrollback 1000
defutf8 on
shell -$SHELL

# Создаем несколько окон
chdir
screen -t Main 1
chdir /etc
screen -t etc 2
chdir /var/log
screen -t logs 3

# Активное первое окно после запуска
select 1

Установка утилит mc, htop, iftop

Следующим шагом я настраиваю некоторые полезные утилиты, которыми регулярно пользуюсь в повседневной работе. Первая из них это всем известный двухпанельный файловый менеджер Midnight Commander. Установим mc на наш сервер:

# apt install mc

И сразу же для него включаю подсветку синтаксиса всех файлов, которые не обозначены явно в файле /usr/share/mc/syntax/Syntax синтаксисом для sh и bash скриптов. Этот универсальный синтаксис нормально подходит для конфигурационных файлов, с которыми чаще всего приходится работать на сервере.

# cp /usr/share/mc/syntax/sh.syntax /usr/share/mc/syntax/unknown.syntax

Я сразу же ставлю редактором по-умолчанию mcedit. Для этого просто выбираю его из меню при первом редактировании какого-нибудь файла. Если у вас такое меню не появляется, можете вызвать его сами и выбрать необходимый редактор по-умолчанию:

# select-editor

Select an editor. To change later, run 'select-editor'.
 1. /bin/nano <---- easiest
 2. /usr/bin/mcedit
 3. /usr/bin/vim.tiny

Choose 1-3 [1]: 2

Так же я рекомендую очень удобный диспетчер задач – htop. Мне он помог, к примеру, решить проблему Взлома сервера CentOS. Ставим его на сервер:

# apt install htop

Полезной утилитой, позволяющей смотреть сетевую загрузку в режиме реального времени, является iftop. Очень рекомендую. Более простого и удобного инструмента мне не попадалось, хотя я много перепробовал подобных вещей. Устанавливаем iftop на сервер:

# apt install iftop

Устаревшая инфраструктура: архивы email-переписок

Меня сбивает с толку тот факт, что в 2021 году у нас по-прежнему нет удобного инструмента для просмотра архивных цепочек обсуждений в почте. Так широко, как в Debian, Email и цепочки писем нигде больше не используются, так что это даже несколько иронично. Использование

вроде и решало эту проблему, но его доступность за последние несколько лет была, мягко говоря, урывистой (сейчас, на момент написания этого поста, он вообще не работает).

Я пытался создать многопоточный архив, но наши лист-мастеры не впечатлились и отказались поддерживать проект.

Устаревшая инфраструктура: багтрекер

Я боюсь взаимодействовать с трекером ошибок Debian. Debbugs — это кусок кода прямиком из 1994 года, который сейчас используется только Debian и проектом GNU.

Процессы Debbugs основаны на использовании электронной почты, то есть проходят асинхронно и громоздко. Несмотря на то, что он работает на самых быстрых машинах, которые мы имеем на проекте Debian (ну так мне сказали, когда эта тема в последний раз поднималась), его веб-интерфейс загружается крайне медленно.

Примечательно, что веб-интерфейс на bugs.debian.org доступен только для чтения. Настроить рабочую зону электронной почты для reportbug (1) или вручную работать с вложениями — довольно серьезный челлендж.

По каким-то причинам, которых я не понимаю, каждое взаимодействие с debbugs приводит к созданию множества цепочек писем.

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

Как бы все это выглядело в идеальном мире?

  1. Debian переключится с нестандартного способа отслеживания ошибок на (любой) уже устоявшийся.
  2. В Debian появляется автоматизация этих процессов. Основной интерфейс должен быть более удобным (например, веб-форма).

Устаревшая инфраструктура: загрузка пакетов

Когда вы хотите сделать пакет доступным в Debian, вы загружаете файлы с подписью GPG через анонимный FTP. Существует несколько видов заданий (the queue daemon, unchecked, dinstall и другие), которые выполняются по фиксированному расписанию (например, dinstall выполняется в 01:52 UTC, 07:52 UTC, 13:52 UTC и 19:52 UTC).

Я подсчитал, что в зависимости от времени суток вы можете подождать более 7 часов (!!!), прежде чем ваш пакет будет установлен.

Но хуже всего для меня то, что обратная связь асинхронна относительно загрузки. Мне нравится что-то сделать, покончить с этим и перейти к следующему заданию. Текущая настройка требует длительного ожидания и, по сути, дорогостоящего переключения между задачами без веских на то технических причин.

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

Последнее сообщение, которое я могу найти об ускорении этого процесса — пост Георга Ganneff Яспирта от 2008 года.

Как бы все это выглядело в идеальном мире?

  1. Анонимный FTP был бы заменен веб-службой, которая принимает мой пакет и возвращает в своем ответе официальное решение о его принятии или отклонении.
  2. Для принятых пакетов есть страница, отображающая статус сборки и время, когда пакет будет доступен через сеть зеркал.
  3. Пакеты должны быть доступны в течение нескольких минут после завершения сборки.

Фрагментированный рабочий процесс и инфраструктура

Обычно Debian предпочитает децентрализованные подходы, а не централизованные. Например, отдельные пакеты хранятся в отдельных репозиториях, а каждый репозиторий может использовать любой SCM (обычно git и svn) или вообще не использовать. Плюс, каждый репозиторий может быть размещен на любом сайте. Конечно, и содержимое каждого репозитория также слегка различается от команды к команде, да даже и внутри команды.

На практике нестандартные варианты хостинга используются достаточно редко, так как они не оправдывают свою стоимость, но достаточно часто, чтобы причинять огромную боль при попытках автоматизировать процесс внесения изменений в пакеты. И вот вместо того, чтобы использовать API GitLab для создания запросов на мерж, вам надо разработать совершенно другую, более сложную систему, которая работает с периодически (или постоянно!) недоступными репозиториями, абстрагирует различия в доставляемых патчах (отчеты об ошибках, запросы на слияние, запросы на извлечение) и прочее, и прочее…

Радикально отличающиеся процессы разработки — это не просто проблема пустой траты рабочего времени. Я участвовал в долгих разговорах о различных процессах разработки git во времена DebConf 13 и понял, что и тогда велись подобные дискуссии.

Лично я не могу держать в голове достаточно подробностей о различных методологиях разработки. Каждый раз, когда я прикасаюсь к пакету, который работает не так, как мой, я очень расстраиваюсь, потому что мне приходится заново изучать аспекты его работы.

Я заметил подобную фрагментацию рабочего процесса в моей собственной команде по пакетированию Go и попытался исправить это с помощью внесения предложений об изменениях в workflow, но не смог их реализовать. Отсутствие эффективной автоматизации и малый темп изменений в инструментарии, несмотря на мою готовность тратить собственное время и энергию, убивали любую мотивацию.

1 Звезда2 Звезды3 Звезды4 Звезды5 Звезд (1 оценок, среднее: 5,00 из 5)
Загрузка...

Оставьте комментарий

Adblock
detector