Вопрос навеян темой VPS vs паранойя, а действительно какими средствами пользуются и пользуются ли провайдеры VPS?

Государство и некоторые ведомства обязуют их, в том или ином виде, собирать поступающую информацию, а проявляют ли сами провайдеры инициативу в отношении клиентских VPS?

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

С другой стороны провайдер может пойти на подобное ради исключения ситуации, когда приходит «товарищ М.» со словами - «Мы тут преступную группировку прикрыли, которая размещала у вас ЦП/продажу запрещенных сильнодействующих/призывы свержения строя 'компартии Китая'» И тут уже последствия могут ограничиваться только фантазией тм.

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

Второго дня «поломался» openvpn, но тут отчасти сам виноват проморгал протухший сертификат сервера, ладно. Вчера отвалилась smb2 на офтопике, прям совсем пропала, пока докопался до истинны за зря перетряс самбу. Сегодня отвалилась аутентификация на почтовом сервере.

ヽ༼ ಠ益ಠ ༽ﾉ

Ситуация следующая Имеется CentOS Linux release 7.9.2009 (Core) с установленным firewalld 0.6.3, где был создан ipset список IP адресов и добавлен в зону «drop». Естественно после этого правила firewalld были перегружены и вроде все хорошо, и списки видятся ... Но доступ с адресов из списка не блокируется.

ЧЯДНТ?

# firewall-cmd --get-ipsets
blacklist

# firewall-cmd --ipset=blacklist --get-entries
101.89.91.196
104.196.16.112
104.248.230.168
104.248.235.0
104.248.240.235
105.235.116.254
...

# firewall-cmd --get-active-zones
drop
  sources: ipset:blacklist
public
  interfaces: ens160

# firewall-cmd --list-all --zone=drop
drop (active)
  target: DROP
  icmp-block-inversion: no
  interfaces:
  sources: ipset:blacklist
  services:
  ports:
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

zfs гуру, подскажите, что не так с руками дисковым пространством. Итак создан RAID-Z пул из 4-х дисков по 1Тб при этом я ожидаю увидеть обещанные (N-1) * размер диска (конечно приближенные), но пул неожиданно оказывается всего 3,62Тб

#zpool list nas_pool                                                                            
NAME       SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP    HEALTH  ALTROOT
nas_pool  3.62T   831G  2.81T        -         -     0%    22%  1.00x    ONLINE  -  

Ладно едем дальше, при выбранной избыточности файловая система должна предоставить 75% от доступного дискового пространства данного пула 3,62 * 0,75 = 2,7Тб

#zfs list nas_pool
NAME       USED  AVAIL     REFER  MOUNTPOINT                                                                  
nas_pool   604G  1.96T      554G  /nas_pool

1,96 + 0,6 ~ 2,6Тб

Шах и мат, аметисты (с) Там 300Гб тут 100Гб что происходит то?

Устал биться, не могу забороть. Скрипты на втором пайтоне ругаются - «Fatal Python error: can't initialize module gtk.gtkgl»

Установленные пакеты:
Name : pygtk
Version : 2.24.0-12

Name : python2-gtkglext
Version : 1.1.0-8

OS Arch
Kernrel 4.19.115-rt48-1-rt-lts

Python 2.7.18 (default, Apr 23 2020, 22:32:06) 
[GCC 9.3.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import gtk
>>> help(gtk)

PACKAGE CONTENTS
    _gtk
    _lazyutils
    compat
    deprecation
    gdkgl (package)
    glade
    gtkgl (package)
    keysyms

>>> import gtk.gtkgl
Fatal Python error: can't initialize module gtk.gtkgl
Aborted (core dumped)

Что смотреть, куда копать?

Ситуация банальна, как символ логотипа МТС. При операции побайтового копирования dd, рука дрогнула и образ диска был записан на диск содержащий раздел /home. На данный момент сам диск содержит раздел с развернутым образом и огромный кусок не распределенного пространства диска. Есть ли какой-нибудь путь восстановить (хотя бы частично) данные? ФС ext4

P.S. Да я делал резервные копии раздела и они есть, но зашифрованные ключом gpg, который хранился в разделе одного из пользователей.

Имееся CentOS 7 без selinux. В качестве MTA установлен Postfix, MDA Cyrus-imapd. Установка и настройка в принципе прошла без особых проблем, почта получалась, отправлялась, но не устраивал тот факт, что аутентификация шла через PAM т.е. каждый новый пользователь должен быть добавлен в систему. Решил перейти на использование sasldb и тут возник затык.

( виртуальный пользователь и его ящик )

Почтовый клиент соединение устанавливает,

( mua log )

Но при этом почта отправленная на этот адрес получает отлуп 550 User unknown. Я так понимаю это ответ postfix т.к. локального пользователя postmaster не существует, дак вот как его заставить искать пользователей в sasldb?

Уважаемые, подскажите, как поступить правильнее и секурнее )) Имеется OpenSSH с авторизацией RSA ключом. Если пользователь заходит с разных машин, то как лучше поступить? Создавать отдельный ключ для каждой машины пользователя или просто создать один ключ и скопировать его на каждую машину с которой пользователь осуществляет вход?

nginx + php-fpm крутятся на CentOS 7 проблема в правах доступа к файлам из скриптов php. Пользователь и группа у всех одинаковые

# ps aux | grep nginx
nginx    18270  0.0  0.1 230388  4748 ?        S    15:49   0:00 php-fpm: pool www
nginx    18311  0.0  0.0  48312  1908 ?        S    15:50   0:00 nginx: worker process

# ls -la test.txt
-rw-rw-rw-. 1 nginx nginx 12 ноя 10 15:32 test.txt

[10-Nov-2014 14:21:16 GMT] PHP Warning:  file_put_contents(test.txt): failed to open stream: 
Permission denied in /var/www/html/test.php on line 3

Centos 7 ставился из образа минимал, т.е. получили практически «пустую» систему. sshd поставился и заработал сразу, без каких либо манипуляций с моей стороны с iptables, а вот после установки vsftpd пришлось писать правило, без этого ftp порт был закрыт. Собственно почему в одном случае заработало «из коробки», а в другом пришлось руками помогать?

Приветствую всех.

На свеже установленную CentOS 7 поставил vsftpd но заставить запустится не могу уже третий день, весь мозг уже набекрень

- Конфиг vsftpd: http://pastebin.com/raw.php?i=2U2nJnRv

- Service status: http://pastebin.com/raw.php?i=BVrZCB55

Прошу дельных советов.

в логах в точности то, что в Service status

Перемещено beastie из general