ServerAdmin.ru
28.7K subscribers
276 photos
34 videos
12 files
2.6K links
Авторская информация о системном администрировании.

Информация о рекламе: @srv_admin_reklama_bot
Автор: @zeroxzed

Второй канал: @srv_admin_live
Сайт: serveradmin.ru
Download Telegram
​​Меня товарищ попросил помочь посчитать, сколько будет стоить купить все необходимые лицензии для работы с файловыми базами на терминальном Windows Server десяти пользователям. Речь идет про бухгалтерию и ЗУП. А потом, если производительности не хватит, сколько понадобится денег, чтобы перейти на вариант с MSSQL сервером. Я посчитал и немного ужаснулся от сумм. Напоминаю, что речь идет про 10 человек.

1-й вариант с файловыми базами:
 :Предприятие 8. Клиентская лицензия на 10 рабочих мест - 41 400 р.
 Microsoft Windows Server Standart 2019 - 70 000 р.
 Microsoft Windows Remote Desktop Services CAL 2019 - 9500 * 10 = 95 000 р.

Посадить 10 человек на терминал с файловыми базами по лицензиям стоит 206 400 р. Добавляем сюда минимум 100 000 р. на железо. Какой-нибудь десктоп с NVMe дисками и хорошим процом. Получается решение примерно на 300 000 р. Я все правильно посчитал?

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

Теперь посмотрим, сколько надо добавить, чтобы переехать на клиент-серверную архитектуру :
 :Предприятие 8. Лицензия на сервер (x86-64) - 86 400 р.
 MS SQL Server Standard 2019 Runtime для пользователей :Предприятие 8 - 22 392 р.
 Клиентский доступ на 10 р.м к MS SQL Server 2019 Runtime для :Предприятие 8 - 113 400 р.

То есть к текущим 300 000 р. добавляем еще 222 000 р. и в сумме получаем 522 000 р.

Как-то перебор, если идти по самому простому пути. И это еще железо бюджетное покупаем. Если закладывать нормальный сервер, то еще + 200 000 р. сверху. Но конкретно с это не обязательно имеет смысл. На современных десктопных процессорах зачастую выдает лучшую производительность за счет высокой частоты отдельного ядра. А по этому параметру большинство серверных процессоров уступают топовым десктопным.

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

#1С
Решил добить тему с публикацией баз в . К прошлой статье в комментах мне сказали, что опубликовать базу можно даже без графического окружения на Linux. Достаточно только веб сервера и некоторых компонентов сервера для Linux. Мне идея понравилась, решил проверить.

И реально, опубликовать базу и настроить доступ через web можно с использованием обычной консоли и веб сервера apache. Проверил все и реализовал на Centos 8.

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

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

https://serveradmin.ru/publikacziya-baz-1s-v-centos/

#1с #статья
​​На днях писал заметку про мониторинг SSD дисков в связи с повышенным расходом ресурса записи. Решил повнимательнее посмотреть на сервер, чтобы понять, кто там так много пишет. Оказалось, что это PostgreSQL и конкретно временные данные статистки, живущие в директории pg_stat_tmp.

Выдержка из документации по поводу этого параметра:

Задаёт каталог, в котором будут храниться временные данные статистики. Этот путь может быть абсолютным или задаваться относительно каталога данных. Значение по умолчанию — pg_stat_tmp. Если разместить целевой каталог в файловой системе в ОЗУ, это снизит нагрузку на физическое дисковое хранилище и может увеличить быстродействие. Задать этот параметр можно только в postgresql.conf или в командной строке при запуске сервера.

В документации указано, что эту директорию можно вынести в ram диск, что я и сделал в итоге. По дефолту она занимает всего 25 мегабайт, так что я решил с запасом сделать диск размером 1G.
mkdir /var/lib/pgsql_stats_tmp
chown postgres:postgres /var/lib/pgsql_stats_tmp

Теперь добавляем в fstab (не забудьте в конце переход на новую строку поставить):
tmpfs /var/lib/pgsql_stats_tmp tmpfs size=1G,uid=postgres,gid=postgres 0 0

Монтируем диск в систему:
mount /var/lib/pgsql_stats_tmp

Меняем параметр в postgresql.conf:
stats_temp_directory = '/var/lib/pgsql_stats_tmp'

Перезапускаем postgresql:
systemctl restart postgrespro-1c-13

Теоретически должна и производительность повыситься, но я не измерял. С учетом того, что SSD и так достаточно быстрый, разница будет не заметна на уровне погрешности измерений.

Как можно было догадаться из названия сервиса postgresql, настраивалось все это для сервера . Так что если вам предстоит переезд на postgresql, заметку сохраните. Наверняка пригодится.

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

#postgresql #1С
Я полностью обновил и переработал свою старую статью по установке и настройке Сервера вместе с базой PostgreSQL на Debian. Постарался собрать в одном месте весь свой опыт по этой теме.

В статье показано:
1️⃣ Установка и настройка сервера и PosgtreSQL.
2️⃣ Привожу пример создания баз данных на этом сервере и подключение к ним.
3️⃣ Бэкап и обслуживание postgresql баз утилитами сервера бд. Рассказываю про свой подход к этому процессу и привожу скрипты автоматизации.
4️⃣ Рассказываю, как тестирую восстановление из дампов и делаю контрольную проверку в виде выгрузки баз в .dt файлы с помощью клиента Linux. Причём последний запускается в консоли без графического окружения. Всё это автоматизируется скриптами.
5️⃣ Рассказываю про свои подходы к мониторингу этих бэкапов и выгрузок, чтобы всегда быть уверенным в том, что у тебя есть гарантированно рабочие бэкапы.

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

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

https://serveradmin.ru/ustanovka-i-nastrojka-1s-na-debian-s-postgresql/

#статья #1с #postgresql
​​На прошлой неделе прочитал достаточно интересную статью - Почему PostgreSQL не лучше MS SQL, где автор сравнил PostgreSQL и MSSQL для использования с . Она мне показалась интересной, поэтому решил сделать для вас выжимку основной информации оттуда, как я её понял!

MSSQL - 20 лет сотрудничества с . К ней все привыкли, у неё лучшие интерфейсы для управления БД с низким порогом входа как для разработчиков, так и поддержки.
 PostgreSQL - настройки в текстовом файле, командная строка Linux, скрипты для обслуживания и бэкапов. Всё это надо изучать, разбираться.
В среднем на MSSQL работает быстрее. Большинство запросов выполняются примерно одинаково. Но бывает так, что на Postgres запросы выполняются значительно медленнее, но обратные ситуации не наблюдаются. То есть Postgres в лучшем случае будет работать так же, разработка под эту БД более требовательна к качеству кода запросов. Ошибок не прощает.
PostgreSQL более экономично относится к памяти, умеет отдавать неиспользованную память обратно системе. MSSQL пожирает всю память, что есть и хочет еще больше.
Бесплатные версии MSSQL и PostgreSQL не сравнимы по функционалу. Последняя уделывает Express версию MSSQL по всем параметрам. Так что по деньгами PostgreSQL будет значительно дешевле, либо вообще бесплатно.
Стоимости MSSQL Enterprise и Postgres Pro Enterprise на одном и том же числе пользователей и железе будут отличаться примерно в 3 раза в пользу Postgres.
У Postgres на Windows много недостатков. Лучше ставить Linux.
У Postgres Pro хорошая русскоязычная поддержка. Реально решают проблемы. Помогают разобрать тормоза конкретных запросов.

Автор статьи - Антон Дорошкевич, руководитель ИТ в компании «Инфософт», в Новосибирске. Является сертифицированным экспертом по эксплуатации PostgreSQL. Уровень сертификата «Эксперт». В течение последних 15-ти лет является эксплуататором больших многокластерных систем на тысячи пользователей и сотни баз – что на MS SQL, что на PostgreSQL.

#1с #postgresql #mssql
​​Мониторинг сервера на Windows в Zabbix

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

У в комплекте есть служба ras, которая выдаёт инфу о кластере. И есть клиент к этой службе rac, который с помощью различных ключей получает от службы нужную информацию.

Регистрируем ras как службу Windows (у меня порты кластера нестандартные, 1640 и 1645 вместо 1540 и 1545):

sc create "1C RAS" binpath= "C:\Program Files (x86)\1cv8\8.3.18.1208\bin\ras.exe cluster --port=1645 localhost:1640 --service" displayname= "1C RAS" start=auto

Запускаем службу и делаем к ней запрос на получение uuid кластера, который нам потом нужен будет во всех запросах:

"C:\Program Files (x86)\1cv8\8.3.18.1208\bin\rac.exe" localhost:1645 cluster list

Запишите полученный uuid кластера. Ниже пример запроса, который покажет все активные сессии:
"C:\Program Files (x86)\1cv8\8.3.18.1208\bin\rac.exe" localhost:1645 session --cluster=62734fb4-f267-4708-9ccf-e929b480b9f4 list

Можно посчитать их количество и на выходе получить просто число:

"C:\Program Files (x86)\1cv8\8.3.18.1208\bin\rac.exe" localhost:1645 session --cluster=62734fb4-f267-4708-9ccf-e929b480b9f4 list | find /c "1CV8C"

Это число мы и передаём в Zabbix с помощью UserParameter. Дальше как обычно - шаблон, айтемы, графики, триггеры. По аналогии вытаскиваются любые другие метрики, которые умеет получать rac. Мне помимо подключений нужна была инфа по BackgroundJob и licenses:

rac session --cluster=uuid list --infobase=uuid | find /c "BackgroundJob"

rac session --licenses --cluster=uuid list

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

#zabbix #1с #windows
​​YaAdmin - бесплатный помощник администратора . Программа с говорящим названием 😁 Только слова в названии не хватает. Прога упрощает мониторинг и управление сервера . Как я понял, написана программистом для привлечения внимания к своим курсам и услугам по аналогии с известной и полезной программой Обновлятор . Код программы закрыт.

YaAdmin  умеет следующее:

Обзор всех процессов, связанных с через встроенный диспетчер задач. Удобно сразу оценить нагрузку, которую создаёт именно .
Мониторинг и управление сессиями на сервере терминалов и RDS. В одном месте видно пользователей терминала и их подключения к серверу , какие ресурсы потребляют их подключения. Можно сразу увидеть, чьем подключение съело всю оперативную память.
Удалённое управление компьютерами пользователей .

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

Нужно понимать, что программа очень простая на основе возможностей самой ОС. Часть функционала реализована через bat файлы (запуск, остановка сервера, сброс подключений и т.д.), которые запускаются через саму программу. Батники эти можно менять. Подобный софт подойдёт для небольших компаний и начинающих админов, которые приглядывают за единственным сервером , который по совместительству является еще и сервером терминалов. Могу порекомендовать такую связку софта для подобного управления: YaAdmin + RDP Defender + Обновлятор-.

Установка и функционал показаны в видео - https://youtu.be/12MI0f0U0_k
Сайт - https://yaadmin.kuharbogdan.com/

#1С #Windows
​​Когда писал предыдущий пост про Yaadmin, упомянул Обновлятор-, про который я вообще ни разу не писал и не вспоминал. А это отличная программа, которую я знаю уже много лет. С её помощью можно в автоматическом режиме обновлять базы данных . Программа пригодится даже тем, у кого только одна файловая база .

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

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

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

Демонстрация работы - https://youtu.be/U5qBBEL7wnY
Сайт - https://helpme1s.ru/obnovlyator-1s-gruppovoe-paketnoe-obnovlenie-vsex-baz-za-odin-raz

#1С
Технический пост, который уже давно нужно было сделать, но всё руки не доходили. На канале много содержательных заметок по различным темам. Иногда сам через поиск ищу то, о чём писал. Ниже набор наиболее популярных тэгов по которым можно найти что-то полезное (и не очень).

#remote - все, что касается удалённого управления компьютерами
#helpdesk - обзор helpdesk систем
#backup - софт для бэкапа и некоторые мои заметки по теме
#zabbix - всё, что касается системы мониторинга Zabbix
#мониторинг - в этот тэг иногда попадает Zabbix, но помимо него перечислено много различных систем мониторинга
#управление #ITSM - инструменты для управления инфраструктурой
#devops - в основном софт, который так или иначе связан с методологией devops
#kuber - небольшой цикл постов про работу с kubernetes
#chat - мои обзоры на популярные чат платформы, которые можно развернуть у себя
#бесплатно - в основном подборка всяких бесплатностей, немного бесплатных курсов
#сервис - сервисы, которые мне показались интересными и полезными
#security - заметки, так или иначе связанные с безопасностью
#webserver - всё, что касается веб серверов
#gateway - заметки на тему шлюзов
#mailserver - всё, что касается почтовых серверов
#elk - заметки по ELK Stack
#mikrotik - очень много заметок про Mikrotik
#proxmox - заметки о популярном гипервизоре Proxmox
#terminal - всё, что связано с работой в терминале
#bash - заметки с примерами полезных и не очень bash скриптов или каких-то команд. По просмотрам, комментариям, сохранениям самая популярная тематика канала.
#windows - всё, что касается системы Windows
#хостинг - немного информации и хостерах, в том числе о тех, кого использую сам
#vpn - заметки на тему VPN
#perfomance - анализ производительности сервера и профилирование нагрузки
#курсы - под этим тэгом заметки на тему курсов, которые я сам проходил, которые могу порекомендовать, а также некоторые бесплатные курсы
#игра - игры исключительно IT тематики, за редким исключением
#совет - мои советы на различные темы, в основном IT
#подборка - посты с компиляцией нескольких продуктов, объединённых одной тематикой
#отечественное - обзор софта из реестра отечественного ПО
#юмор - большое количество каких-то смешных вещей на тему IT, которые я скрупулезно выбирал, чтобы показать вам самое интересное. В самом начале есть шутки, которые придумывал сам, проводил конкурсы.
#мысли - мои рассуждения на различные темы, не только IT
#разное - этим тэгом маркирую то, что не подошло ни под какие другие, но при этом не хочется, чтобы материал терялся, так как я посчитал его полезным
#дети - информация на тему обучения и вовлечения в IT детей
#развитие_канала - серия постов на тему развития данного telegram канала

Остальные тэги публикую общим списком без комментариев, так как они про конкретный софт, понятный из названия тэга:
#docker #nginx #mysql #postgresql #gitlab #asterisk #openvpn #lxc #postfix #bitrix #икс #debian #hyperv #rsync #wordpress #zfs #grafana #iptables #prometheus #1с #waf #logs #netflow
​​Знакомлю вас с необычным продуктом, аналогов которого я не видел. Речь пойдёт о веб панели для управления кластером , причем не важно, где установленном, на Windows или Linux. У программы, на мой взгляд, не очень удачное название - Панель управления сервисами и компонентами (ПУСК). По нему совершенно не понятно, о чём идёт речь, плюс используется употребляемое в других значениях слово пуск.

Программа бесплатная, написана на Java. Внешний вид максимально приближённо копирует интерфейс штатной консоли для администрирования . Для управления кластером используются стандартные возможности Сервера администрирования кластера (ras), который входит в поставку технологической платформы :Предприятие 8.

С помощью ПУСК можно выполнять привычные действия:
управление кластерами (на различных серверах, с различными версиями платформы );
управление информационными базами ;
управление сеансами и блокировками;
управление рабочими процессами и серверами;
управление менеджерами кластера;
статистика использования лицензий.

Как я уже сказал, программа написана на Java, так что для запуска достаточно установить Java версии не ниже 17 и запустить jar файл. Ну и не забыть открыть на фаерволе 8080 порт. Дальше всё делается через браузер. Инструкция по установке есть в архиве с программой, в папке doc. Авторы программы русскоязычные, так что всё подробно описано.

❗️Программа пока находится в статусе беты. Идёт активная разработка. В ближайшем релизе ожидается доработка скриптов запуска, интерфейса, тёмная тема, возможно в этом, либо следующем релизе массовая обработка над информационными базами.

Сам я программу не пробовал, так как нет сейчас подходящего стенда под неё. Да и времени особо тестами заниматься тоже нет. Идея, как по мне, отличная. Если выйдет в релиз, точно буду пользоваться. Для серверов под Linux очень кстати будет.

Сайт - https://it-expertise.ru/pusk/
Обсуждение - https://infostart.ru/public/1713088/

#1С
❗️Подобные новости не мой формат, но на всякий случай предупреждаю, так как походу завтра эпичная массовая проблема будет:

Критично: срочно, сегодня обновите платформу ":Предприятие 8"!
https://1c.ru/news/info.jsp?id=29958

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

Фирма "" доводит до сведения пользователей и партнеров, что в версиях платформы ":Предприятие" 8.3.22.1672, 8.3.22.1603, 8.3.21.1607, 8.3.21.1508, 8.3.21.1484, 8.3.20.2076, 8.3.20.2039, 8.3.19.1665, 8.3.19.1659, 8.3.18.1902, 8.3.18.1894, 8.3.17.2733, 8.3.17.2665 обнаружена критическая проблема, которая может привести к закрытию приложения в начале работы с программой.

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

Проблема не приводит к потере данных пользователей.

Положил платформу windows64full_8_3_22_1704.rar к себе на Яндекс.Диск для тех, кто тоже не сможет сам скачать:
https://disk.yandex.ru/d/f5rJTFMavNWwJQ

#1С
последнее время стала часто менять установщик сервера под Linux. Сначала с переходом на единый дистрибутив поменялся процесс обновления и установки сервера. А теперь по мере изменения версий в рамках единого установщика тоже происходят заметные изменения. То gnome на сервер автоматом ставит, а не так давно вместо скрипта запуска для init.d, появился unit для systemd.

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

1️⃣ Останавливаем сервер . В зависимости от установленной версии, команда будет выглядеть по-разному. До 8.3.21 вот так:
# systemctl stop srv1cv83
После 8.3.21 примерно так:
# systemctl stop srv1cv8-8.3.21.1484@default

2️⃣ Я рекомендую сохранить настройки кластера из домашней директории /home/usr1cv8/.1cv8/1C/1cv8. Только текстовые файлы с настройками, больше ничего. У меня разок была ситуация, когда обновлял тестовый сервер, где .1cv8 была символьной ссылкой на другой том. По какой-то причине она была заменена на новую пустую директорию. Когда запустил сервер, очень удивился, что в списке баз пусто. А их там было штук 30. Сервер хоть и тестовый, я всегда сначала на нём проверял обновления, но всё равно перспектива добавления заново всех баз не радовала. Решил детальнее разобраться, что случилось и заметил, что символьная ссылка пропала. Вернул её на место и все базы восстановились.

Тем не менее, у меня были ситуации, когда я терял настройки сервера. Хоть и некритично, но всё равно неприятно. Лишняя работа. Рекомендую параметры сохранять перед обновлением.

3️⃣ Качаем дистрибутив единого установщика и копируем на сервер. Имя файла имеет примерно такой формат: server64_8_3_22_1709.tar.gz. Распаковываем:
# tar xzvf server64_8_3_22_1709.tar.gz
Можно сразу запустить установщик ./setup-full-8.3.22.1709-x86_64.run и интерактивно выбрать все настройки, либо запустить в пакетном режиме, указав необходимые настройки. Например:
# ./setup-full-8.3.22.1709-x86_64.run --mode unattended \
--enable-components server,ws,client_full
Установили компоненты: Сервер , модуль расширения веб сервера, толстый клиент.

4️⃣ Если раньше был скрипт запуска в /etc/init.d/srv1cv83, удаляем его. Вместо него устанавливаем юнит systemd:
# systemctl link /opt/1cv8/x86_64/8.3.22.1709/srv1cv8-8.3.22.1709@.service
Добавляем в автозагрузку и запускаем:
# systemctl enable srv1cv8-8.3.22.1709@.service
# systemctl start srv1cv8-8.3.22.1709@.default
Обращаю внимание, что команда на запуск изменилась. Нужно добавлять имя экземпляра сервера. По умолчанию - default. Так сделано для того, чтобы было удобно запускать несколько разных экземпляров сервера с разными настройками на одном хосте, повесив их на разные порты.

5️⃣ Напомню, что управлять кластером можно с помощью бесплатной панели управления ПУСК. Если у вас оснастки администрирования установлены на Windows машине, не забудьте там обновить платформу и зарегистрировать утилиту администрирования новой версии, иначе не получится подключиться к обновлённому серверу. Я частенько забываю это сделать.

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

#1с
​​Хочу поделиться информацией по поводу публикации баз по HTTP. Регулярно получаю вопросы по этой теме, очень актуальная. Да и статьи писал не раз по этому поводу. У меня есть довольно большой практический опыт настройки и поддержки работы таких баз.

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

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

Ограничения это ладно, с ними можно разобраться, так как они известны. Но, к сожалению, через браузер иногда возникают проблемы с работой основного функционала. Это бывает не часто, но бывает. Я сталкивался не раз и не два. Например, обновляется Chrome и какой-то запрос при работе с базой начинает зацикливаться и блокироваться браузером. При этом в том же Firefox продолжает нормально работать. В следующем обновлении платформы или конфигурации это может быть исправлено, а может и нет. Также сталкивался с тем, что какие-то то ли формы, то ли отчёты или другой функционал не открывался через браузер. Ошибка появлялась тоже после очередного обновления. Решения тупо нет, надо сидеть и ждать, либо откатываться назад. Ситуация очень неприятная.

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

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

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

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

#1С
Я обновил и актуализировал популярную на сайте статью по настройке сервера :

Установка и настройка на Debian с PostgreSQL
https://serveradmin.ru/ustanovka-i-nastrojka-1s-na-debian-s-postgresql/

Статья подробная. Позволяет простым копированием и ставкой настроить указанную связку. В ней показаны:

Установка и настройка свежей версии сервера и PosgtreSQL 15 на Debian 11.
Пример создания баз данных на этом сервере и подключение к ним.
Бэкап и обслуживание postgresql баз утилитами сервера бд. Рассказываю про свой подход к этому процессу и привожу скрипты автоматизации. 
Как я тестирую восстановление из sql дампов и делаю контрольную проверку в виде выгрузки баз в .dt файлы в консоли Linux. Всё это автоматизируется скриптами. 
Рассказываю про свои подходы к мониторингу этих бэкапов и выгрузок, чтобы всегда быть уверенным в том, что у тебя есть гарантированно рабочие бэкапы.

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

#1с #postgresql
Недавно планово обновлял один из серверов в связке с PostgreSQL, работающий на Debian. Сервер настроен примерно так же, как описано в моей статье:
⇨ Установка и настройка на Debian с PostgreSQL
А обновление делал по этой статье:
⇨ Обновление Сервера под Linux

Статьи в целом актуальны. Обновление сделал сначала на тестовом сервере клоне. Обновил, проверил работу сервера, баз. Всё нормально. Потом перешёл к рабочему. Обновил штатно, но начались проблемы.

Выражалось это в том, что раза в 2-3 возросла нагрузка по CPU. В целом, всё работало, но очень медленно. Через панель администрирования было видно большое количество фоновых задач. При этом они не висели, но выполнялись явно медленно, поэтому их было в списке аномально много. Больше обычного в несколько раз.

Какое-то время разбирался в проблеме, пытаясь понять, с чем это связано. Полный дублёр этого сервера не имел таких проблем. В итоге заглянул в лог postgresql и заметил, что там куча сообщений об исчерпании лимита доступных подключений, хотя в обычное время их достаточно. Судя по всему по какой-то причине на боевом сервере зависли соединения.

Остановил сервер , перезапустил postgresql и запустил заново сервер. Работа нормализовалась. Контроль соединений к базе данных — один из ключевых параметров, которые надо мониторить. Здесь это не было сделано. Пришло время настроить.

На что ещё обратить внимание при обновлении:
1️⃣ Периодически установщик ставит дополнительные пакеты. Например, в этот раз заметил, что он установил Apache. Мне он был не нужен, удалил.
2️⃣ Проверьте, что вы точно удалили из автозапуска службу со старой версией . Я в одном месте ошибся и удалил неправильно. Там немного отличаются команды. Например, остановка сервиса выполняется командой:
# systemctl stop srv1cv8-8.3.22.1709@.default
А удаление из автозапуска:
# systemctl disable srv1cv8-8.3.22.1709@.service
Окончания в названиях службы разные. Я в одном месте ошибся и после перезагрузки получил две запущенные службы сервера. Старая запустилась в качестве сервера, а новая версия валилась в ошибки постоянно. Самое удивительное, что заметили это только через 3 дня, так как платформа у клиентов автоматически использовала старую версию и никто не обратил на это внимание.

#1С