Как настроить vsFTPd с виртуальными пользователями на CentOS 6.6

делать надо так:

# cd /etc/vsftpd
# vim vusers.txt

site1.com
site1_password
site2.com
site2_password

На основе этого файла сгенерируем базу данных Berkley, которая будет использоваться PAM для аутентификации наших виртуальных пользователей и поместим полученный файл в директорию /etc/vsftpd (чтобы по феншую)

# db_load -T -t hash -f vusers.txt vsftpd-virtual-user.db

Шаг 3. Зададим файл конфигурации PAM для vsftpd использующий сгенерированную базу данных. Создадим файл /etc/pam.d/vsftpd-virtual

#%PAM-1.0
auth required pam_userdb.so db=/etc/vsftpd/vsftpd-virtual-user
account required pam_userdb.so db=/etc/vsftpd/vsftpd-virtual-user
session required pam_loginuid.so

Внимание! Путь к файлу базы данных в конфигурации PAM задаётся без расширения .db, хотя такое расширение у файла имеется! В противном случае, PAM будет говорить о том, что не нашёл указанный файл. Это очень странная особенность с которой приходится считаться

Шаг 4. Теперь необходимо сконфигурировать сам vsftpd. Зададим содержимое файла /etc/vsftpd/vsftpd.conf:

# Отключает анонимный доступ

anonymous_enable=NO

# Включает не-анонимный (sic!) доступ

local_enable=YES

# Активирует поддержку виртуальных пользователей

guest_enable=YES guest_username=ftp

# Виртуальные пользователи используют локальный привилегии (а не анонимные)

virtual_use_local_privs=YES

# Включает поддержку записи

write_enable=YES

# Файл конфигурации PAM для vsftpd. Совпадает с именем файла конфигурации в /etc/pam.d

pam_service_name=vsftpd-virtual

# Следующие две строчки определяют локальные директории для пользователей

# В данном случае это будут /var/www/<имя пользователя>

user_sub_token=$USER
local_root=/var/www/$USER

# Виртуальные пользователи ограничены своим каталогом

chroot_local_user=YES

# Убирает передачу реальных идентификаторов групп и пользователей файлов

hide_ids=YES

# Запустить

# vsftpd listen=YES

# Слушать данные на порту 20

# connect_from_port_20=YES

# Маска для создания новых файлов

local_umask=022

Полный конфиг

listen=YES
listen_port=21
ftp_data_port=20
connect_from_port_20=YES
nopriv_user=ftp
ftp_username=ftp
idle_session_timeout=300
port_enable=YES
anonymous_enable=YES
anon_root=/home/ftp/anonymous
no_anon_password=YES
anon_mkdir_write_enable=NO
anon_other_write_enable=NO
anon_upload_enable=NO
chown_uploads=YES
chown_username=ftp
anon_umask=022
local_enable=YES
local_root=/home/ftp/$USER
chroot_local_user=YES
local_umask=022
chmod_enable=YES
banner_file=/etc/vsftpd/banner
dirmessage_enable=YES
message_file=.message
dirlist_enable=YES
ls_recurse_enable=NO
mdtm_write=YES
deny_file={.message}
use_localtime=YES
guest_enable=YES
guest_username=ftp
user_config_dir=/etc/vsftpd/user_config/$USER
user_sub_token=$USER
download_enable=YES
write_enable=YES
ascii_download_enable=YES
ascii_upload_enable=YES
lock_upload_files=YES
virtual_use_local_privs=YES
pam_service_name=vsftpd
secure_chroot_dir=/var/run/vsftpd

Запоминаем в куках галочку

Плагин

https://raw.githubusercontent.com/carhartl/jquery-cookie/master/src/jquery.cookie.js

            // read the current/previous setting
            $("#dont_show_message").each(function() {
                var name = $(this).attr('name');
                if ($.cookie(name) && $.cookie(name) == "true") {
                    $(this).prop('checked', $.cookie(name));
                }
            });
            // event management
            $("#dont_show_message").change(function() {
                var name = $(this).attr("name");
                $.cookie(name, $(this).prop('checked'), {
                    path: '/',
                    expires: 365
                });
            });

Отправка почты через postfix


Шаг 1.
Нужно заиметь учётку на работающем почтовике, чтобы мы могли юзать его как relay. Делается не сложно, просто обращаемся к админу того сервера с соответсвующей просьбой. Ну реализацию этого шага я думаю по деталям разъяснять  не стоит.

Шаг 2.
Открываем /etc/postfix/main.cf и ищем там настройку relayhost. Она отвечает за пересылку почты через релай. Указываем адрес, по которому нам доступен почтовик в локалке.

relayhost = [mail.local]
Тут mail.local - это и есть этот адрес.

Шаг 3.
Авторизация на релай-сервере. Отрываем тот же /etc/postfix/main.cf и дописываем такие строки:

defer_transport = smtp
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/saslpass
Это мы активировали функию авторизации через SASL. Учтите, если авторизация какая-то хитро-мудрая, то этот способ может не подойти, на этот счёт лучше поговорить с вашим админом.

Далее в файо /etc/postfix/saslpass, который мы указали раннее прописываем логин а пароль от сервера.

mail.local relayuser@mail.local:password
На всякий случай комментирую: первое - это адрес сервера, второе - логин, третье (после двоеточия) - это пароль. После этого создаём хешированную таблицу (которую postfix и будет читать).

# postmap /etc/postfix/saslpass
Остаётся перегрузить настройки postfix.

# /etc/init.d/postfix reload
Вот собственно и всё. Можно работать. Главное корректно задавать адрес отправителя в заголовках, ибо может не прокатить.


честно стырено с http://adment.org.ua/admin/21-postfix-relay

Amazon S3 около четырех часов работал с перебоями

28 февраля 2017 года, примерно в 21:00 по московскому времени перестали отвечать сервисы  amazon s3 US-EAST-1 региона. Продолжалось все это безобразие 4 часа 17 минут, в это время не работали задачи Trello, платформа Coursera, сервис вопросов Quora, пользователи жаловались на проблемы в работе Open Whisper Systems, Quora, IFTTT, рассылок Sailthru, Business Insider, Giphy, Medium, Slack, Coursera, различных фотохостингов и так далее.

Что же случилось? Если вкратце — человеческая ошибка, один из админов выполнил команду группового удаления сервисов, но вместо одной (небольшой) группы серверов, он выключил другую, почти целиком остановив биллинг (и все остальное) на S3 в этом регионе.

https://aws.amazon.com/ru/message/41926/

 

Стоит добавить, что недавно,  31  января 2017 так же из-за человеческой ошибки пострадал GitLab, когда сотрудник их компании, хотел почистить слейв БД, дропнув ее, но перепутал сервера, и дропнул мастер.

https://docs.google.com/document/d/1GCK53YDcBWQveod9kfzW-VCxIABGiryG7_z_6jHdVik/pub

Сертификаты

Еще раз про сертификаты для сервера.

Если что то не выходит делаем следующие проверки.

1. ключ подходит с серитфикату.

Проверяем MD5 ключа и сертификата:

# openssl rsa -noout -modulus -in serov.1.key | openssl md5
(stdin)= 777711dbbab90e1b12e922bbdbde6716
# openssl x509 -noout -modulus -in serov.crt | openssl md5
(stdin)= 910a2dd2db8510094383563ed18c056d

Если строчки разные, то ключ не подходит к сертификату.

Ну и можно посмотреть что внутри

  • Check a Certificate Signing Request (CSR)
    openssl req -text -noout -verify -in CSR.csr
  • Check a private key
    openssl rsa -in privateKey.key -check
  • Check a certificate
    openssl x509 -in certificate.crt -text -noout