Статтю перенесено до тематичного блогу: pravdak.blogspot.com.
У цьому блозі залишено матеріали з програмування, адміністрування й техніки.
У цьому записі збереглося лише повідомлення про перенесення. Посилання веде на головну сторінку тематичного блогу; повного тексту перенесеної статті тут немає.
У цьому випадку 2013 року дані рахунків із Depoer потрібно було переносити до Oberone. Програма Undepoer частково формувала Excel-файл із бази, але перед завантаженням користувачі вручну додавали рядки та відомості про компанію, що управляє цінними паперами.
Для тисяч записів це забирало багато часу й створювало ризик механічної помилки. Ми підготували макрос, який вставляє рядки та заповнює задані поля.
Код збережено з оригінальними назвами й рядками-заповнювачами. Значення NumRows = 2495, активна комірка та структура аркуша стосуються вихідного прикладу.
Sub Макрос1()
Rows("3:3").Select
NumRows = 2495
NumRows = NumRows*2
For x = 2 To NumRows+1
If (x Mod 2) = 0 Then
ActiveCell.Rows.EntireRow.Select
Selection.Insert Shift:=xlDown, CopyOrigin:=xlFormatFromLeftOrAbove
End If
If (x Mod 2) = 0 Then
Cells(x+1, 1).FormulaR1C1 = "Тут заполняем информацию в 1-й ячейке"
Cells(x+1, 2).FormulaR1C1 = "Заполняем код компании"
Cells(x+1, 3).FormulaR1C1 = "Заполняем название компании"
Cells(x+1, 4).FormulaR1C1 = "Заполняем название компании"
End If
ActiveCell.Offset(1, 0).Select
Next
End SubМакрос починає з виділення третього рядка. Початкове значення NumRows подвоюється, а цикл перевіряє парність x: на парних кроках вставляється рядок і записуються значення в перші чотири стовпці. Після кожного кроку активне виділення зміщується на рядок униз. Тому кількість записів і початкова позиція мають відповідати саме вашому файлу.
Працюйте з копією файлу. Замініть заповнювачі фактичними значеннями, перевірте кількість рядків, розташування стовпців і початкове виділення. Спочатку виконайте перевірку на невеликому наборі та звірте сформовані записи до імпорту.
Метод Range.Insert у документації Microsoft вставляє комірки або діапазон зі зсувом наявних даних. Цей макрос — приклад підготовки конкретного файлу, а не універсальний конвертер для всіх версій Depoer та Oberone.
Одного дня знайомий надіслав мені запрошення до LinkedIn. Я зареєструвався, підтвердив запрошення, і невдовзі почали надходити запити від інших людей. Коли я впізнавав людину, зазвичай додавав її до своєї мережі.
За якийсь час я помітив, що людям з мого списку контактів надходять запрошення від мого імені. Це стало для мене несподіванкою. Я намагався зупинити розсилку й видалити контакти, але підказки із запрошеннями продовжували з’являтися. Тоді, у 2013 році, я також не знайшов, де закрити свій акаунт.
Після цього випадку я уважніше дивлюся на те, що саме підтверджую в соціальних мережах. Додати знайому людину до мережі, надати доступ до адресної книги й надіслати запрошення — три різні дії. Якщо сервіс пропонує вибрати одержувачів, варто переглянути цей список до підтвердження.
Тепер у довідці LinkedIn є окремі інструкції для цих дій. У налаштуваннях акаунта можна видалити раніше імпортовані контакти. Якщо запрошення вже надіслане й ще очікує відповіді, його можна відкликати в розділі запрошень. Для закриття акаунта LinkedIn описує окрему процедуру.
Статтю перенесено до тематичного блогу: pravdak.blogspot.com.
У цьому блозі залишено матеріали з програмування, адміністрування й техніки.
У цьому записі збереглося лише повідомлення про перенесення. Посилання веде на головну сторінку тематичного блогу; повного тексту перенесеної статті тут немає.
Під час підключення до термінального сервера через RDP я іноді бачив повідомлення, що сеанс відключено через відсутність клієнтської ліцензії віддаленого робочого стола. Якщо це трапляється лише на одному комп’ютері, варто перевірити локальний кеш ліцензій. Якщо помилка виникає на кількох клієнтах, почніть із перевірки сервера ліцензування.
HKEY_LOCAL_MACHINE\Software\Microsoft\MSLicensing на клієнтському комп’ютері.MSLicensing, як описано в інструкції Microsoft.mstc.exe через «Запустити від імені адміністратора» і повторно підключіться. Після успішного підключення завершіть сеанс і перевірте, чи працює наступне підключення зі звичайними правами.Після очищення клієнт може повідомити, що віддалений комп’ютер завершив сеанс через помилку в протоколі ліцензування. Таке буває, коли клієнт не має прав повторно записати дані в реєстр. Саме для цього перше підключення запускають із підвищеними правами. У моїй нотатці 2013 року дані, які відтворюються в гілці, позначено як HardwareID і StoreID.
Якщо повторне підключення з підвищеними правами не допомогло або проблема виникла одночасно на кількох комп’ютерах, перевірте в RD Licensing Diagnoser доступність сервера ліцензування, налаштований режим ліцензування та наявність сумісних RDS CAL. Очищення клієнтського кешу не додає ліцензій на сервері. Діагностика ліцензування RDS від Microsoft.
У квітні 2013 року виникла потреба запустити другий екземпляр Apache, використовуючи той самий виконуваний файл. Для незалежної роботи потрібно розділити конфігурації, адреси й порти прослуховування, PID-файли та журнали. Два процеси самі по собі не створюють відмовостійкого сервісу.
Нижче збережено початкові команди для середовища з SysV init та пояснено помилки в узгодженні шляхів. На сучасній системі спосіб керування службою слід узгодити з її пакетом і менеджером служб.
Початкова схема спиралася на /etc/apache2/apache2.conf, /etc/apache2/ports.conf і /etc/apache2/envvars. Журнали задавалися директивами:
ErrorLog /var/log/apache2/error.log
CustomLog /var/log/apache2/other_vhosts_access.log vhost_combinedУ старій системі копіювали init-скрипт та додавали його в автозапуск:
cd /etc/init.d
cp apache2 apache2_srv
update-rc.d apache2_srv defaultsПрактично спочатку варто завершити налаштування й перевірку, а вже потім вмикати автозапуск. У скрипті замість початкового блока:
PIDFILE=`. /etc/apache2/envvars ; echo $APACHE_PID_FILE`
if [ -z "$PIDFILE" ] ; then
echo ERROR: APACHE_PID_FILE needs to be defined in /etc/apache2/envvars >&2
exit 2
fiвикористовували окремий файл середовища:
PIDFILE=`. /etc/apache2/envvars_apache2_srv ; echo $APACHE_PID_FILE`
if [ -z "$PIDFILE" ] ; then
echo ERROR: APACHE_PID_FILE needs to be defined in /etc/apache2/envvars_apache2_srv >&2
exit 2
fiENV="env -i LANG=C PATH=/usr/local/bin:/usr/bin:/bin APACHE_ENVVARS=/etc/apache2/envvars_apache2_srv"
cp /etc/apache2/envvars /etc/apache2/envvars_apache2_srvУ копії змінювали PID-файл:
export APACHE_PID_FILE=/var/run/apache2.pidна:
export APACHE_PID_FILE=/var/run/apache2_apache_2.pidОкремий файл портів у першій частині нотатки називався /etc/apache2/ports_apache_srv.conf і містив:
Listen 81Для журналів наводилися такі команди:
touch /var/log/apache2/error_apache2_srv.log
touch /var/log/apache2/other_vhosts_access_apache2_srv.log
chown root:root /var/log/apache2/other_vhosts_access_apache2_srv.log
chown root:adm /var/log/apache2/error_apache2_srv.log
chmod 640 /var/log/apache2/error_apache2_srv.logУ старому init-скрипті був такий блок запуску; у тому середовищі кеш не використовувався:
start)
log_daemon_msg "Starting web server" "apache2"
if $APACHE2CTL start; then
if check_htcacheclean ; then
log_progress_msg htcacheclean
start_htcacheclean || log_end_msg 1
fi
log_end_msg 0
else
log_end_msg 1
fi
;;Початковий виклик:
APACHE2CTL="$ENV /usr/sbin/apache2ctl"замінювали на:
APACHE2CTL="$ENV /usr/sbin/apache2ctl -f /etc/apache2/apache2_srv.conf"Відповідно змінювали команди:
$APACHE2CTL -k start
$APACHE2CTL -k stop
$APACHE2CTL -k graceful
$APACHE2CTL -tДокументація Apache пояснює: -f вибирає конфігурацію, -k задає дію керування, -t перевіряє синтаксис. Потрібні саме узгоджені налаштування цільового екземпляра.
Початок функції у старому скрипті:
pidof_apache() {
# if pidof is null for some reasons the script exits automagically
# classified as good/unknown feature
PIDS=`pidof apache2` || trueпропонувалося замінити таким фрагментом:
pidof_apache() {
# if pidof is null for some reasons the script exits automagically
# classified as good/unknown feature
PIDS=`ps aux | grep 'apache2_srv' | grep -v 'grep' | awk '{print $2}' | xargs` || trueОбидва уривки є лише початками функції. Пошук через grep залежить від тексту командного рядка й може вибрати не той процес. Загальний pidof apache2 також не розрізняє потрібні екземпляри. Для керування слід використовувати відповідну службу та її окремий PidFile.
Перша спроба в нотатці завершилася так:
/etc/init.d/apache2_srv start
Starting web server: apache2apache2: Could not open configuration file
/etc/apache2/apache2_failover.conf: No such file or directory
failed!Помилка посилалася на apache2_failover.conf, хоча вище було задано apache2_srv.conf. Перед запуском потрібно виправити всі виклики, щоб вони посилалися на один обраний файл. У нотатці його створювали так:
cp /etc/apache2/apache2.conf /etc/apache2/apache2_srv.confНаприкінці наводилися:
CustomLog /var/log/apache2/other_vhosts_access_apache2_srv.log vhost_combined
ErrorLog /var/log/apache2/error_apache2_srv.log
Include /etc/apache2/ports_apache2_srv.confТут є ще одна розбіжність: раніше файл портів називався ports_apache_srv.conf, без «2» після apache. Назва у Include має точно збігатися з реально створеним файлом. Перевірте також, чи не підключає новий конфіг спільні файли з конфліктними Listen, віртуальними хостами або PID-шляхами.
У початковому тексті згадувалися NameVirtualHost xx.xx.xx.xx:80 та VirtualHost xx.xx.xx.xx:81. Адреси й порти потрібно узгоджувати з Listen. У сучасній гілці Apache 2.4 NameVirtualHost вже не впливає на роботу.
Старий запис завершувався успішним запуском:
/etc/init.d/apache2_srv start
Starting web server: apache2.Для реальної перевірки потрібні успішний тест конфігурації, окремі PID і журнали, відповідь на потрібному порту та підтвердження, що зупинка другого екземпляра не зачіпає перший.
Ця нотатка 2013 року описувала мою перевірку сеансів, SSH, firewall, sudo та вебсервера. Деякі тодішні висновки були надто категоричними. Нижче збережено команди й приклади, але уточнено, що саме вони можуть підтвердити.
whor tty7 2013-03-11 06:52 (:0)
r pts/2 2013-04-03 05:21 (192.168.3.62)
r pts/6 2013-04-03 08:27 (192.168.3.62)
r pts/5 2013-04-03 07:58 (192.168.3.62)
(unknown) tty8 2013-04-03 06:16 (:1)
(unknown) tty9 2013-04-03 08:28 (:2)
(unknown) tty10 2013-04-03 08:47 (:3)Позначка (unknown) сама по собі не доводить стороннього проникнення. Потрібно зіставити сеанс із процесами, диспетчером входу та журналами автентифікації.
who -a -pзавантаження системи 2013-03-11 06:54
рівень виконання 2 2013-03-11 06:54
ВХІД tty4 2013-03-11 06:54 1575 id=4
ВХІД tty5 2013-03-11 06:54 1581 id=5
ВХІД tty2 2013-03-11 06:54 1588 id=2
ВХІД tty3 2013-03-11 06:54 1589 id=3
ВХІД tty6 2013-03-11 06:54 1593 id=6
r + tty7 2013-03-11 06:52 да 4824 (:0)
ВХІД tty1 2013-03-11 06:52 5937 id=1
pts/2 2013-03-11 06:57 0 id=/2 термінал=0 вихід=0
r + pts/2 2013-04-03 05:21 01:26 2104 (192.168.3.62)
r + pts/6 2013-04-03 08:27 . 409 (192.168.3.62)
pts/7 2013-03-11 11:45 0 id=/7 термінал=0 вихід=0
pts/8 2013-04-03 09:21 15957 id=ts/8 термінал=0 вихід=0
pts/10 2013-04-03 09:13 14507 id=s/10 термінал=0 вихід=0
pts/12 2013-03-11 10:18 19235 id=s/12 термінал=0 вихід=0
pts/14 2013-03-11 10:31 21030 id=s/14 термінал=0 вихід=0
r + pts/5 2013-04-03 07:58 00:05 23871 (192.168.3.62)
pts/3 2013-04-03 07:36 5537 id=ts/3 термінал=0 вихід=0
pts/7 2013-04-03 09:17 10140 id=ts/7 термінал=0 вихід=0
pts/9 2013-04-03 09:14 14013 id=ts/9 термінал=0 вихід=0
pts/11 2013-03-19 18:33 6218 id=s/11 термінал=0 вихід=0
pts/13 2013-03-11 22:14 17281 id=s/13 термінал=0 вихід=0
pts/15 2013-03-11 22:33 18853 id=s/15 термінал=0 вихід=0
pts/17 2013-03-11 21:52 19310 id=s/17 термінал=0 вихід=0
pts/6 2013-03-25 07:43 0 id=/6 термінал=0 вихід=0
pts/8 2013-03-25 07:43 0 id=/8 термінал=0 вихід=0
(unknown) + tty8 2013-04-03 06:16 да 5873 (:1)
(unknown) + tty9 2013-04-03 08:28 да 813 (:2)
tty10 2013-04-03 09:10 7691 id=:3 термінал=0 вихід=0У старому випадку я завершував процеси так:
kill 5873 813PID належать лише до того знімка стану. На іншій системі ці числа можуть відповідати зовсім іншим процесам. Перед завершенням потрібно встановити власника, призначення й наслідки; за підозри на інцидент також зберегти потрібні журнали та свідчення.
Пересилання графічних застосунків контролює параметр у /etc/ssh/sshd_config:
X11Forwarding no
/etc/init.d/ssh restartЦе не те саме, що повністю заборонити віддалений вхід чи будь-який доступ до робочого столу. Початкова згадка про X11 «за замовчуванням» залежала від системи; у поточній довідці OpenSSH базовим значенням є no, а дистрибутив може мати власну конфігурацію.
Історичне посилання з нотатки: http://d51x.ru/page/udalennyj-dostup-x11-forwarding.
У первинному тексті наводилися такі параметри:
Port 22
ListenAddress 0.0.0.0
AllowUsers user1 user2 user3
/etc/init.d/ssh restartPort 22 є стандартним портом, а 0.0.0.0 означає прослуховування всіх IPv4-адрес, не звуження доступу до однієї адреси. Зміна порту може зменшити фонове сканування, але не замінює автентифікацію та правила доступу. AllowUsers потрібно узгоджувати з реальними обліковими записами. Перед перезапуском перевірте конфігурацію й збережіть спосіб відновлення віддаленого доступу.
apt-get install arno-iptables-firewallУ нотатці конфігурація пов'язувалася з /etc/arno-iptables-firewall/conf.d:
EXT_IF="eth0 ppp0"
EXT_IF_DHCP_IP=1
# 3343,4434 - Порты для администрирования svn
# 9000 - порт для darkstat
# 3389 - терминал Windows
# 1500 - ???
# 8080 - порт для доступа к svn
# 1500 - ISP админка
# 440 - новый номер порта для ssh
# 22 - был ssh УБРАН
OPEN_TCP="80,443,21,6543,47,3343,4434,8080,1500,440"
# 110,25,995
OPEN_UDP=""
INT_IF="eth1"
NAT=0
INTERNAL_NET="192.168.3.0/24"
NAT_INTERNAL_NET="eth1"
OPEN_ICMP=1
LAN_OPEN_TCP="80,443,21,6543,1723,47,3389,1500,9000,5900,440"invoke-rc.d arno-iptables-firewall restartЦе перелік потреб конкретного старого сервера, а не рекомендований набір відкритих портів. Відкривайте тільки потрібні служби. Число 47 у списку TCP-портів не означає дозвіл GRE як IP-протоколу; відповідні мережеві механізми різні.
Початковий приклад /etc/sudoers:
# User privilege specification
#root ALL=(ALL:ALL) ALL
r ALL=(ALL:ALL) ALL
# Members of the admin group may gain root privileges
#%admin ALL=(ALL) ALL
# Allow members of group sudo to execute any command
#%sudo<>ALL=(ALL:ALL) ALL
# See sudoers(5) for more information on "#include" directives:
#includedir /etc/sudoers.dНе слід механічно коментувати root, групи чи включення каталогу: це може зламати передбачений порядок адміністрування. Спочатку визначте необхідні права, резервний адміністративний доступ і наявні правила. Для редагування використовуйте visudo, який перевіряє синтаксис. Старий фрагмент збережено разом із його особливостями форматування.
У старій нотатці рекомендувався складний пароль щонайменше з 12 символів і наводилася команда:
passwd rootДовжина сама по собі не гарантує захисту. Політика root, парольна автентифікація та SSH-доступ мають розглядатися разом; команда не є обов'язковим кроком для кожної Ubuntu-інсталяції.
У початковому матеріалі було наведено:
curl -I -H "Request-Range: bytes=0-1,0-2,0-3,0-4,0-5,0-6" -s Ваш домен/robots.txt | grep PartialВідповідь 206 Partial Content не є достатнім доказом вразливості. Вона може відображати звичайну підтримку часткових відповідей. Реальну вразливість потрібно перевіряти за версією, конфігурацією та офіційними повідомленнями безпеки, а не цим одним рядком.
Тоді пропонувалися такі зміни:
sudo a2enmod headers
proxy_set_header Range "";
proxy_set_header Request-Range "";
SetEnvIf Range (?:,.*?){5,5} bad-range=1
RequestHeader unset Range env=bad-range
RequestHeader unset Request-Range
/etc/init.d/apache2 restartФрагменти належать до різних конфігурацій: proxy_set_header — до Nginx, SetEnvIf і RequestHeader — до Apache. Їх не можна вставляти як один конфіг. Вони можуть змінювати поведінку завантажень і не замінюють оновлення.
Apache описує Range-вразливість CVE-2011-3192 як історичну проблему, виправлену в гілці 2.2. Сама гілка 2.2 вже завершила підтримку. Для робочого сервера потрібні підтримувані версії та перевірені налаштування.
Для початкової діагностики Linux часто достатньо читати системні файли за допомогою cat. Віртуальна файлова система /proc надає відомості ядра про поточний стан системи.
cat /proc/cpuinfo — відомості про процесор.cat /proc/meminfo — стан оперативної пам’яті.cat /proc/interrupts — лічильники переривань.cat /proc/swaps — активні області підкачування.cat /proc/version — версія ядра та відомості про його складання.cat /proc/net/dev — мережеві інтерфейси та їх статистика.cat /proc/mounts — змонтовані файлові системи.cat /proc/partitions — відомості про розділи блокових пристроїв.cat /proc/modules — завантажені модулі ядра.cat /etc/issue — текст привітання перед входом, який може містити назву дистрибутива.Ці команди читають дані та не змінюють конфігурацію. Вміст /proc відображає поточний стан, а не вичерпний паспорт усього обладнання; доступність окремих відомостей залежить від ядра та середовища запуску.
Файл /etc/issue, на відміну від решти списку, не належить до /proc. Це налаштовуваний текст привітання, тому його не слід вважати безумовно точним джерелом версії операційної системи.
Детальний опис системних файлів: The /proc Filesystem — документація ядра Linux.
Лист із командного рядка можна підготувати через mail або сумісну реалізацію mailx. Для доставки потрібна налаштована поштова система або SMTP-транспорт; наявність команди сама по собі не забезпечує надсилання.
Початковий приклад:
mail -s "Тема письма" pupkin@mail.ru
Привет!
Я пишу тебе из консоли!
Ctrl+DCtrl+D на новому рядку завершує введення. Це комбінація клавіш, а не текст для листа. Запит копії та наступні дії залежать від реалізації клієнта.
mail -s "Письмо из файла" pupkin@mail.ru < mail_body.txt
ls | mail -s "Вывод команды" pupkin@mail.ruКодування uuencode:
uuencode image.jpg image.jpg | mail -s "Метод 1" sombeody@somewhere.netЦе закодований вміст у повідомленні, який не всі клієнти розпізнають як звичайне MIME-вкладення. Інший спосіб — mpack:
mpack -s "Метод 2" image.jpg sombeody@somewhere.netУ початковому прикладі Mutt використовувався так:
echo "Смотри вложение" | mutt -x -s "Метод 3" -a image.jpg sombeody@somewhere.netПоточна документація Mutt показує відокремлення одержувачів від файлів через --. Відповідний варіант:
echo "Смотри вложение" | mutt -x -s "Метод 3" -a image.jpg -- sombeody@somewhere.netЗагальне твердження, що mail не підтримує вкладень, неточне: можливості й параметри залежать від конкретної програми. Перевіряйте її локальну довідку. Утиліти можуть потребувати встановлення з репозиторію дистрибутива.
Адреси й російськомовні рядки в командах збережено як частину оригінального коду. Перед використанням замініть одержувачів на потрібні вам. Автор початкової нотатки — Raa; оригінал про листи та вкладення з консолі.
У березні 2013 року провайдер повідомив, що через наш сервер надсилається спам. На ньому працював Exim4, тому я почав із журналу поштових операцій:
tail -f /var/log/exim4/mainlogЗа тодішніми спостереженнями, сервер приймав зовнішні спроби пересилання з адресами відправників, для яких у нас не було скриньок. Сама відсутність локальної скриньки ще не встановлює джерело повідомлення чи причину проблеми: потрібно перевіряти журнали приймання, автентифікацію та правила relay.
Щоб припинити потік, я тимчасово закрив поштові порти брандмауером. Такий крок зупиняє й потрібні з'єднання, тому його слід узгоджувати з призначенням сервера.
У початковій публікації залишилися три записи відмови RCPT і один запис розриву з’єднання. Під час публікації адресні поля були перетворені на HTML-теги та атрибути. Нижче показано саме збережений фрагмент джерела як текст, щоб браузер більше не приховував ці частини. Це не відновлені адреси й не новий журнал сервера:
2013-03-27 07:30:32 H=118-232-93-18.dynamic.kbronet.com.tw [118.232.93.18] F=<knead574 regentcomm.com=""> rejected RCPT <sales sova-dpr.com.ua="">: relay not permitted</sales></knead574>
2013-03-27 07:30:35 H=118-232-93-18.dynamic.kbronet.com.tw [118.232.93.18] F=<workhousescsg rayberndtson.com=""> rejected RCPT <sales sova-dpr.com.ua="">: relay not permitted</sales></workhousescsg>
2013-03-27 07:30:37 H=118-232-93-18.dynamic.kbronet.com.tw [118.232.93.18] F=<tiffedxsr67 royaldelft.com=""> rejected RCPT <sales sova-dpr.com.ua="">: relay not permitted</sales></tiffedxsr67>
2013-03-27 07:30:37 unexpected disconnection while reading SMTP command from 118-232-93-18.dynamic.kbronet.com.tw [118.232.93.18] (error: Connection reset by peer)Не слід додавати символи @ чи відновлювати адреси здогадками. Для встановлення точних envelope sender і recipient потрібен вихідний mainlog. Натомість дата, час, хост підключення, повідомлення relay not permitted та факт розриву з’єднання в наявному фрагменті читаються.
За цими записами можна зробити вузький висновок: показані спроби RCPT були відхилені. Вони не доводять, що до того сервер був відкритим relay, що інші повідомлення не приймалися або що конкретна конфігураційна зміна остаточно усунула причину скарги.
У первинній нотатці були наведені дві команди очищення:
exipick -zi | xargs exim -MrmПерша відбирає заморожені повідомлення.
exipick -i | xargs exim -MrmДруга видаляє всі відібрані повідомлення черги, а не лише спам. Статус frozen також сам собою не означає небажану пошту. Перед видаленням перегляньте відбір, збережіть потрібні повідомлення й матеріали для аналізу. За документацією Exim, -Mrm прибирає повідомлення без сповіщення про недоставлення. Параметри відбору пояснює довідка exipick.
У моєму випадку пошта була потрібна для повідомлень від сайтів на самому сервері. У /etc/exim4/update-exim4.conf.conf тоді були задані:
dc_local_interfaces='127.0.0.1'
dc_readhost='localhost'Ці параметри виконують різні завдання. dc_local_interfaces визначає адреси, на яких слухає демон; значення 127.0.0.1 обмежує його IPv4 loopback-адресою. dc_readhost стосується переписування адрес у відповідних режимах конфігурації й не є загальною забороною relay. Це пояснює довідка Debian.
Після змін я перезапускав службу:
service exim4 restartПотім у журналі бачив rejected RCPT ...: relay not permitted. Це підтверджувало відмову в конкретних спробах пересилання. Однак якщо демон справді слухає лише 127.0.0.1, пряме зовнішнє TCP-з'єднання до нього не має доходити. Тому старі рядки журналу не можна автоматично вважати доказом, що саме наведені два параметри усунули всі причини інциденту.
Для чинного сервера перевірте ефективну конфігурацію, адреси прослуховування, правила relay, потрібне надсилання від сайтів і зовнішню відмову. Очищення черги саме по собі не виправляє причину небажаного надсилання.
У журналі Exim важливо розрізняти події одного повідомлення: <= позначає приймання, => — доставлення, == — відкладену спробу, а ** — помилку доставлення. Запис Completed означає завершення обробки та вилучення повідомлення з черги, а не доказ того, що адресат прочитав лист.
Для розбору збирають пов’язану послідовність за ідентифікатором повідомлення: звідки його отримано, чи була автентифікація, які одержувачі оброблялися та чим закінчилася кожна спроба. Поле відправника саме по собі не встановлює особу, яка надіслала лист.
/etc/exim4/exim4.conf може мати пріоритет перед автоматично згенерованим файлом.Результат такого розбору — підтверджений шлях повідомлення та перевірені правила приймання. Масове видалення черги або закриття портів можуть тимчасово прибрати симптом, але самі по собі не пояснюють його походження.
Додаткове джерело: офіційний опис журналів Exim.
SaaS (Software as a Service) — модель надання програмного забезпечення як послуги: користувач працює із застосунком постачальника через мережу, а постачальник керує його серверним середовищем. Типові приклади — вебпошта, CRM, офісні та інші бізнес-застосунки.
Замість окремого сервера, інсталяції та власного циклу оновлень компанія отримує доступ до готового сервісу. Це змінює спосіб оплати й розподіл роботи між замовником та постачальником. Перевага стає відчутною тоді, коли сервіс закриває потрібний процес, а його обмеження зрозумілі ще до перенесення даних.
За визначенням NIST SP 800-145, у моделі SaaS клієнт використовує застосунки постачальника, які працюють у хмарній інфраструктурі. Доступ можливий через браузер або програмний інтерфейс. Клієнт не керує базовими серверами, операційними системами й інфраструктурою, хоча може мати доступ до налаштувань свого застосунку.
Це зменшує обсяг локального встановлення та серверного адміністрування. Водночас підприємству залишаються налаштування процесів, навчання, перенесення даних, інтеграції та керування користувачами. SaaS не означає автоматичного впровадження без роботи з боку замовника.
Часто застосовується багатоклієнтська архітектура: спільні компоненти обслуговують кількох замовників із розмежуванням їхніх даних і доступу. Постачальник централізовано розвиває та оновлює сервіс. Огляд Microsoft пояснює такий підхід і його зв'язок з економією ресурсів.
Однак формула «всі клієнти завжди використовують один екземпляр програми» надто спрощує можливі реалізації. Важливі модель надання послуги, розподіл відповідальності й фактична ізоляція клієнтів. Самого розміщення звичайної програми на віддаленому сервері недостатньо для опису всіх властивостей хмарного сервісу.
Поширені тарифи — за користувача, обсяг даних, операції або набір можливостей. Можуть бути змішані та безкоштовні варіанти. Щомісячна плата не є обов'язковою частиною самого технічного визначення SaaS.
Порівнювати варто повну вартість за потрібний період: підписку, впровадження, інтеграції, навчання, додаткові модулі, зберігання та вивантаження даних. Менші початкові витрати не гарантують нижчої загальної вартості в кожному проєкті.
Припинення роботи в сервісі не завжди автоматично припиняє платежі. Можливість паузи, строк підписки, порядок скасування, склад підтримки та зміни тарифів визначаються умовами конкретної послуги. Не слід обіцяти, що будь-який SaaS-контракт включає всі роботи й витрати.
Угода про рівень обслуговування (SLA) описує погоджені показники: наприклад, доступність, спосіб її обчислення, винятки, реакцію підтримки та передбачені компенсації. Важливо читати саме ці параметри, а не лише відсоток у рекламі.
Показники 99,5% і 99,9% мають сенс лише разом із правилами вимірювання: за який період рахують доступність, що вважають простоєм, як враховують технічні роботи та які звернення потрібні для компенсації. Доступність інфраструктури й доступність усього застосунку також потрібно розрізняти. У рекомендаціях NIST щодо хмарних послуг окремо розглянуто обіцянки постачальника, їхні обмеження й умови користування.
Для клієнта SaaS може спростити початок роботи, доступ із різних місць і пристроїв та отримання оновлень. Для постачальника централізована підтримка й повторне використання спільних компонентів можуть зменшувати витрати на обслуговування. Періодичні платежі дають іншу модель доходів, але не гарантують прибутковості.
Інтерфейс, продуктивність, сумісність і якість підтримки потрібно оцінювати на практиці. Вебдоступ не робить будь-яку програму однаково зручною на всіх екранах, а масштабування не означає відсутності лімітів.
У власній інсталяції підприємство оплачує не тільки ліцензію. Потрібні серверні ресурси, їх обслуговування, оновлення, моніторинг і робота фахівців. У сервісній моделі частина цих витрат розподіляється між багатьма замовниками. Постачальник може повторно використовувати інфраструктуру й механізми оновлення, замість того щоб окремо супроводжувати кожну локальну копію.
Але ефект масштабу не є обіцянкою необмеженої продуктивності. Важливо розуміти, як сервіс поводиться за пікового навантаження, які має квоти й коли знадобиться дорожчий план. Для замовника практичний результат — не найменший щомісячний рахунок, а передбачувана вартість потрібного робочого сценарію.
Вебсервіс полегшує доставку змін: користувачам не потрібно по черзі встановлювати нову серверну версію у своїх офісах. Постачальник отримує централізований канал розвитку продукту й може пропонувати його віддаленим клієнтам. Водночас він бере на себе постійну експлуатацію: доступність, підтримку, відновлення після збоїв і планування ресурсів.
Серверний код зазвичай не передається клієнту, що змінює характер ризику неліцензійного копіювання. Проте залишаються ризики викрадення облікових записів, порушення правил доступу та неправомірного використання сервісу. Повторюваний дохід так само потребує витрат на розробку, продажі й утримання клієнтів. Його не варто плутати з гарантованим прибутком.
Передавання частини адміністрування постачальнику не усуває відповідальності клієнта. Модель спільної відповідальності Microsoft окремо виділяє дані, облікові записи, налаштування й контроль доступу. Конкретний розподіл завдань залежить від сервісу.
Потрібно перевірити доступи, резервування й відновлення, експорт даних та порядок завершення користування. Не можна загалом стверджувати, що будь-який SaaS безпечніший за будь-яку внутрішню систему або повністю виключає витік.
Якість мережевого з'єднання залишається суттєвою, зокрема для розподілених компаній. Офлайн-режим є лише там, де його реалізовано, і може мати обмеження синхронізації. Індивідуальні доопрацювання теж залежать від можливостей конкретної платформи.
Залежність від постачальника — реальний предмет оцінки. Важливі доступність експорту, формат даних та можливість перейти на інше рішення. У своїй критиці серверних обчислень Річард Столлман наголошує на втраті контролю користувача над обробкою його даних. Це аргумент про свободу й контроль, а не доказ порушень з боку кожного сервісу.
SaaS надає готовий застосунок. PaaS надає середовище для розгортання власних застосунків. Це різні моделі послуг у класифікації NIST; PaaS не є автоматичним усуненням усіх обмежень SaaS.
Оренда обчислювальних ресурсів існувала й до сучасних вебсервісів. Водночас користування віддаленою машиною та доступ до готового застосунку — різні речі. Класифікацію хмарних моделей NIST опублікував у 2011 році; вона допомагає відокремити те, чим керує клієнт, від того, що обслуговує постачальник.
Первинне джерело історичної добірки: стаття Вікіпедії про SaaS. Для практичного вибору сервісу вирішальними є потрібні функції, перевірений робочий сценарій, умови доступу до даних і повна вартість користування.
У 2013 році в Україні почали діяти дві окремі податкові пільги для індустрії програмної продукції. Одна стосувалася ПДВ при постачанні програмної продукції, інша — податку на прибуток підприємств, які відповідали визначеним критеріям і пройшли реєстрацію. Режими діяли різний час. Ставка 5% для цієї категорії підприємств діяла у 2013–2014 роках, а пільга з ПДВ закінчилася 1 січня 2023 року.
Пільга діяла з 1 січня 2013 року до кінця 2022 року. У початковому переліку програмної продукції були операційні системи, системні, прикладні, навчальні й розважальні програми та їхні компоненти, сайти, онлайн-сервіси й криптографічні засоби захисту інформації. Згодом норма змінювалася. Для історичної операції важлива редакція пункту 26¹ підрозділу 2 розділу XX Податкового кодексу на дату операції. Повідомлення ДПС про завершення пільги.
Знижена ставка поширювалася на прибуток від визначених видів діяльності. За правилами, запровадженими Законом № 5091-VI, підприємство мало відповідати чотирьом критеріям за попередні чотири послідовні квартали:
Новостворені підприємства, що відпрацювали щонайменше два повні квартали, могли використати показники за фактичний період діяльності. Підприємства, які виникли внаслідок реорганізації, приватизації чи корпоратизації, для цієї процедури новоствореними не вважалися.
Керівник або уповноважений представник юридичної особи подавав заяву до податкового органу за місцезнаходженням підприємства щонайменше за 30 календарних днів до початку кварталу, з якого підприємство планувало скористатися режимом. Податкова могла перевірити документи протягом 10 робочих днів. За відсутності підстав для відмови вона мала протягом 15 робочих днів від отримання заяви включити підприємство до реєстру та видати або надіслати свідоцтво. Режим застосовували з першого числа місяця після включення до реєстру.
Доходи й витрати за видами діяльності, що підпадали під пільгу, обліковували окремо. Амортизацію основних засобів, використаних для отримання прибутку за пільговою ставкою, не переносили до інших витрат.
Початковий закон передбачав довший строк для ставки 5%, але Закон № 71-VIII виключив відповідний пункт із Податкового кодексу з 1 січня 2015 року. Пільга з ПДВ мала окрему норму й діяла до кінця 2022 року. Тому в документах за минулі роки варто розрізняти податок на прибуток підприємства і ПДВ за конкретною операцією.
У березні 2013 року ДПС пояснила, як відрізнити постачання програмної продукції від окремих послуг з інформатизації. Від цієї відмінності залежало, чи могла операція підпадати під тодішнє звільнення від ПДВ. Пільга діяла з 1 січня 2013 року до кінця 2022 року.
У початковій редакції норми до програмної продукції належав результат програмування: операційні системи, системні, прикладні, навчальні й розважальні програми та їхні компоненти. До переліку також входили вебсайти, онлайн-сервіси й криптографічні засоби захисту інформації. Пільгу передбачив Закон України від 5 липня 2012 року № 5091-VI, який змінив перехідні положення Податкового кодексу.
У листі від 5 березня 2013 року № 3360/6/15-3115 ДПС пояснювала, що окремі послуги з проєктування, видання, програмування, тестування, встановлення, впровадження й обслуговування ПЗ не підпадали під звільнення для постачання програмної продукції.
Для історичної операції варто звірити предмет договору, умови щодо майнових прав, склад ціни й дату постачання. Наприклад, у роз’ясненні 2016 року податкова окремо розглянула технічну підтримку, яку надає сторонній виконавець і яка не входить у вартість програми. Для такої послуги вона вказала загальний порядок оподаткування.
З 1 січня 2023 року пільговий режим за пунктом 26¹ підрозділу 2 розділу XX Податкового кодексу припинив дію. ДПС підтвердила це в повідомленні про завершення пільги. Для операцій за минулі періоди перевіряйте редакцію Кодексу, чинну на дату відповідної операції.
Один із моїх клієнтів у 2013 році, навчаючись працювати з ISPmanager, видалив користувача, від імені якого було створено домени. За моїм спостереженням, після цього зникли домени та пов'язані з ними дані.
Головний висновок — перед видаленням облікового запису потрібно перевірити всі належні йому ресурси: сайти, файли, пошту, бази та резервні копії. Видалення користувача може зачіпати значно більше, ніж сам запис для входу.
Поведінка операції залежить від версії й конфігурації панелі. Для сучасної інсталяції перевірте опис операції та повідомлення підтвердження. Документація ISPmanager про копії видалених користувачів окремо описує копії даних видалених користувачів; можливість відновлення залежить від наявності й придатності такої копії.
У старій інсталяції ISPmanager я зіткнувся зі зникненням доменів зі списку панелі. Водночас записи залишалися в конфігураціях Apache та Nginx. Отже, йшлося про відображення ресурсів у панелі, а не про видалення цих конфігурацій.
Після звернення до підтримки я продовжив діагностику самостійно. Спочатку в /usr/local/ispmgr/etc/ispmgr.conf увімкнув докладне журналювання:
LogLevel 9Для спостереження за новими записами використовував:
tail -n 1 -f /usr/local/ispmgr/var/ispmgr.logПроцеси панелі переглядав командою:
ps aux | grep ispmУ тодішній конфігурації я завершував процес bin/ispmgr; після нового звернення до панелі він запускався знову. У журналі після перезапуску з'явилися повідомлення про права доступу.
Причиною виявилася невідповідність користувача, зазначеного в Apache, власникові каталогу домену. Після виправлення власника та повторного запуску панелі домен знову відобразився.
Шляхи, параметр журналювання й спосіб перезапуску належать до тієї версії. Перед змінами у своїй системі звірте документацію, зафіксуйте поточні права й перевірте потрібного власника; не змінюйте права всіх каталогів навмання. Після діагностики поверніть звичайний рівень журналювання.
Демонстраційна база швидко відкривається, презентація переконлива, а справжня перевірка починається перед відправленням машин: склад проводи...
