Домой /  Интернет / Подключение 1с через веб сервер. Настройка и использование веб-браузеров. Общая схема работы с информационными базами «1С:Предприятие» через веб-браузер

Подключение 1с через веб сервер. Настройка и использование веб-браузеров. Общая схема работы с информационными базами «1С:Предприятие» через веб-браузер

Начиная с версии платформы 1С 8.3, появилась возможность опубликовывать информационные базы на веб-серверах. Данное решение очень удобно, ведь перейдя по ссылке в браузере, вы сможете полноценно работать в 1С. Обратите внимание, что работа возможно только в режиме «Предприятие» Использовать конфигуратор можно только на толстом клиенте.

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

В данной статье мы пошагово рассмотрим публикацию информационной базы 1C 8.3 на веб-сервере с использованием Apache. Описанные ниже настройки, которые мы будем производить в самой 1С, ничем не отличаются от публикации на веб-сервере IIS.

Единственное отличие — сервер под управлением IIS более «привередливый» к настройкам, поэтому чаще всего выбор падает именно на Apache.

Установка и настройка Apache 2.4

Первым делом нужно скачать сам Apache, например, с официального сайта . Актуальная на данный момент версия 2.4. В процессе установки нет ничего сложного, достаточно следовать помощнику.

Когда при установке перед вами отобразится окно с информацией о сервере, введите в первых двух полях «localhost». Это будет означать, что наш компьютер и будет являться сервером, на котором расположена 1С.

Так же обратите внимание, что у нас будет использоваться порт 80 (переключатель внизу формы). Важно, чтобы он не был занят другими приложениями.

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

Публикация информационной базы 1С 8.3

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

Выберите в меню «Администрирование» пункт «Публикация на веб-сервере». В открывшемся окне мы оставим все настройки по умолчанию, изменив лишь малую их часть.

В качестве веб-сервера выберем Apache 2.2, который установили ранее. В качестве имени можно указать произвольное значение. Мы публикуем 1С:Документооборот, поэтому назовем ее просто «doc». В поле каталог выберем так же созданную нами пустую папку, которая может быть расположена в любом месте.

После внесения всех необходимых данных, нажмем на кнопку «Опубликовать» и перезапустим веб-сервер Apache.

Теперь в адресной строке браузера введем «localhost/doc». Перед нами появилось окно авторизации в 1С.

После введения логина с паролем и аутентификации, перед нами откроется привычная нам 1С.

31/05/2016

Настройка веб-сервера Microsoft Internet Information Services (IIS) для работы с платформами 1С:Предприятие

Общие сведения о публикациях

Как известно, публикация баз данных 1С может осуществляться как из конфигуратора, так и с помощью утилиты webinst. Подробнее алгоритм публикации описан на ИТС, например, по данной ссылке .

Стоит обратить внимание, что публикация для 64-разрядного сервера возможна только из конфигуратора в ОС Linux или с помощью утилиты webinst. На некоторых наших нагрузочных тестах 64-разрядные веб-сервера IIS показали чуть лучшую производительность, поэтому, в отсутствие других ограничений, мы рекомендуем использовать именно их.

Если же вы планируете использовать 32-разрядный веб-сервер IIS, тогда не забудьте разрешить запуск 32-битных приложений: в списке «Пулы приложений» («Application Pools») для каждого нужного пула нажать правую кнопку мыши, в контекстном меню выбрать «Дополнительные параметры…» («Advanced Settings»), затем задать параметр «Разрешены 32-разрядные приложения» («Enable 32-bit Applications») в значение «Истина» («True»).

В документации также описано несколько важных пунктов относительно работы с веб-сервером IIS. Процитируем их: при публикации на веб-сервере IIS следует помнить, что:

  • Публикация всегда выполняется для веб-сайта по умолчанию (Default Web Site).
  • Публикация всегда выполняется для пула приложений по умолчанию (DefaultAppPool).
  • Для пула приложений, используемого для работы «1С:Предприятия», должна быть отключена поддержка.NET. Для этого следует установить свойство пула приложений «Версии среды.NET Framework» («.NET Framework Version») в значение «Без управляемого кода» («No Managed Code»).

Информация по первым двум пунктам важна и сама по себе, и особенно в контексте рассматриваемого вопроса, так как пригодится нам в дальнейшем. Третья рекомендация, по нашему опыту, не является обязательной и веб-сервер IIS успешно работает в режиме использования версии, например, .NET Framework v4.

Настройка IIS для разных версий платформы 1С

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

Итак, создадим для примера два дополнительных пула приложений (в общем случае их может быть больше), для удобства укажем в названии пула версию платформы, с которой планируем их использовать (мы указали версию сокращенно — «8.3.6», но вам может быть удобнее использовать полную версию, например, «8.3.6.2237», или вообще разделить пулы приложений по прикладному признаку, например, «пул тестового кластера»). Зададим рекомендованные параметры (версия среды, признак использования 32-битных приложений). В итоге должны увидеть следующий список пулов приложений веб-сервера IIS:

Далее, запускаем конфигуратор (не забываем выполнять это действие от имени администратора) и выполняем публикацию. Как и указано в документации, появляется (или обновляется, если публикация уже выполнялась ранее) запись о новом сайте в группе «Default Web Site». В дополнительных параметрах этой публикации будет указан пул приложений по умолчанию - «DefaultAppPool». Для его изменения можно вызвать диалог «Дополнительные параметры…» или «Основные настройки…». Вызываем основные:

Заменяем пул приложений по умолчанию («DefaultAppPool») на пул приложений, соответствующий версии платформы 1С публикуемой базы («AppPool 1C 8.3.6» или «AppPool 1C 8.3.7»).

Если требуется изменить обработчик модулей расширения веб-сервера (например, после публикации из конфигуратора с 32-битной на 64-битную версию), можем сделать это здесь же:

Поступаем аналогичным образом для другой информационной базы и другой версии платформы 1С.

На этом все необходимые настройки завершены! Проверяем и наслаждаемся одновременной работой с веб-приложениями 1С разных версий в рамках одного веб-сервера:

Заключение

В статье мы описали метод, позволяющий использовать несколько публикаций информационных баз в рамках одного веб-сервера IIS для информационных баз «1С:Предприятие» разных версий. Это необходимо, если вы работаете на сервере с несколькими рабочими или тестовыми базами, для которых используемые версии платформы 1С различаются.

Надеемся, вы сможете с легкостью выполнить нужную вам задачу и продолжите с удовольствием пользоваться продуктами 1С. Ну а если у вас что-то не получится, или вы столкнетесь с какими-то трудностями, мы обязательно поможем!

Одной из приятных особенностей технологии 1С:Предприятие является то, что прикладное решение, разработанное по технологии управляемых форм, может запускаться как в тонком (исполняемом) клиенте под Windows, Linux, MacOS X, так и как веб-клиент под 5 браузеров – Chrome, Internet Explorer, Firefox, Safari, Edge, и все это – без изменения исходного кода приложения. Более того – внешне приложение в тонком клиенте и в браузере функционирует и выглядит практически идентично.
Найдите 10 отличий (под катом 2 картинки):

Окно тонкого клиента на Linux:

То же окно в веб клиенте (в браузере Chrome):

Зачем мы сделали веб-клиент? Говоря несколько пафосно, такую задачу перед нами поставило время. Уже давно работа через Интернет стала необходимым условием для бизнес-приложений. Вначале мы добавили возможность работы через Интернет для нашего тонкого клиента (некоторые наши конкуренты, кстати, на этом и остановились; другие, напротив, отказались от тонкого клиента и ограничились реализацией веб-клиента). Мы же решили дать нашим пользователям возможность выбрать тот вариант клиента, который им подходит больше.

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

Постановка задачи

Итак, требования к проекту: веб-клиент должен делать то же самое, что и тонкий клиент, а именно:
  1. Отображать пользовательский интерфейс
  2. Исполнять клиентский код, написанный на языке 1С
Пользовательский интерфейс в 1С описывается в визуальном редакторе, но декларативно, без попиксельной расстановки элементов; используется около трех десятков типов элементов интерфейса - кнопки, поля ввода (текстовые, цифровые, дата/время), списки, таблицы, графики и т.д.

Клиентский код на языке 1С может содержать в себе серверные вызовы, работу с локальными ресурсами (файлами и т.п.), печать и многое другое.

И тонкий клиент (при работе через веб), и веб-клиент пользуются одним и тем же набором веб-сервисов для общения с сервером приложений 1С. Реализация у клиентов, конечно, разная – тонкий клиент написан на С++, веб-клиент – на JavaScript.

Немного истории

Проект создания веб-клиента стартовал в 2006 году, в нем (в среднем) участвовала команда из 5 человек. На отдельных этапах проекта привлекались разработчики для реализации специфической функциональности (табличного документа, диаграмм и т.д.); как правило, это были те же разработчики, что делали эту функциональность в тонком клиенте. Т.е. разработчики заново писали на JavaScript компоненты, ранее созданные ими на C++.

С самого начала мы отвергли идею какой-либо автоматической (хотя бы частичной) конверсии C++ кода тонкого клиента в JavaScript веб-клиента ввиду сильных концептуальных различий этих двух языков; веб-клиент писался на JavaScript с чистого листа.

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

Первая версия платформы 1С:Предприятие с поддержкой веб-клиента вышла в 2009 году. Веб-клиент на тот момент поддерживал 2 браузера – Internet Explorer и Firefox. В первоначальных планах была поддержка Opera, но из-за непреодолимых на тот момент проблем с обработчиками закрытия приложения в Opera (не удавалось со 100%-ной уверенностью отследить, что приложение закрывается, и в этот момент произвести процедуру отключения от сервера приложений 1С) от этих планов пришлось отказаться.

Структура проекта

Всего в платформе 1С:Предприятие есть 4 проекта, написанных на JavaScript:
  1. WebTools – общие библиотеки, используемые остальными проектами (сюда же мы включаем Google Closure Library).
  2. Элемент управления ФорматированныйДокумент
  3. Элемент управления Планировщик (реализован на JavaScript и в тонком клиенте, и в веб-клиенте)
  4. Веб-клиент
Структура каждого проекта напоминает структуру Java-проектов (или.NET проектов – кому что ближе); у нас есть неймспейсы, и каждый неймспейс лежит в отдельной папке. Внутри папки лежат файлы и классы неймспейса. В проекте веб-клиента около 1000 файлов.

Структурно веб-клиент по-крупному разделяется на следующие подсистемы:

  • Управляемый интерфейс клиентского приложения
    • Общий интерфейс приложения (системные меню, панели)
    • Интерфейс управляемых форм, включающий, в том числе, около 30 элементов управления (кнопки, различные типы полей ввода – текстовые, цифровые, дата/время и пр., таблицы, списки, графики и т.д.)
  • Объектная модель, доступная разработчикам на клиенте (всего более 400 типов: объектная модель управляемого интерфейса, настройки компоновки данных, условного оформления и пр.)
  • Интерпретатор встроенного языка 1С
  • Расширения браузеров (используются для функциональности, не поддерживаемой в JavaScript)
    • Работа с криптографией
    • Работа с файлами
    • Технология внешних компонент, позволяющая их использовать как в тонком, так и веб-клиенте

Особенности разработки

Реализация всего вышеописанного на JavaScript – дело непростое. Возможно, веб-клиент 1С – одно из самых больших client-side приложений, написанных на JavaScript – около 450.000 строк. Мы активно используем в коде веб-клиента объектно-ориентированный подход, упрощающий работу с таким большим проектом.

Для минимизации размера клиентского кода мы вначале использовали свой собственный обфускатор, а начиная с версии платформы 8.3.6 (октябрь 2014) стали использовать Google Closure Compiler . Эффект использования в цифрах – размер фреймворка веб-клиента после обфускации:

  • Собственный обфускатор – 1556 кб
  • Google Closure Compiler – 1073 кб
Использование Google Closure Compiler помогло нам повысить быстродействие веб-клиента на 30% по сравнению с нашим собственным обфускатором. Кроме того, на 15-25% (в зависимости от браузера) снизился объем памяти, потребляемой приложением.

Google Closure Compiler очень хорошо работает с объектно-ориентированным кодом, поэтому его эффективность именно для веб-клиента максимально высокая. Closure Compiler делает для нас несколько хороших вещей:

  • Статическая проверка типов на этапе сборки проекта (обеспечивается тем, что мы покрываем код аннотациями JSDoc). В итоге получается статическая типизация, очень близкая по уровню к типизации в С++. Это помогает отловить достаточно большой процент ошибок на стадии компиляции проекта.
  • Уменьшение размера кода через обфускацию
  • Ряд оптимизаций выполняемого кода, например, такие как:
    • inline-подстановки функций. Вызов функции в JavaScript – достаточно дорогая операция, и inline-подстановки часто используемых небольших методов существенно ускоряют работу кода.
    • Подсчет констант на этапе компиляции. Если выражение зависит от константы, в него будет подставлено фактическое значение константы
В качестве среды разработки веб-клиента мы используем WebStorm.

Для анализа кода мы используем SonarQube , куда интегрируем статические анализаторы кода. С помощью анализаторов мы отслеживаем деградацию качества исходного кода на JavaScript и стараемся ее не допускать.

Какие задачи решали/решаем

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

Обмен данными с сервером и между окнами

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

/** * @constructor * @extends {Base.SrvObject} */ Srv.Core.GenericException = function () { /** * @type {string} * @expose */ this.descr; /** * @type {Srv.Core.GenericException} * @expose */ this.inner; /** * @type {string} * @expose */ this.clsid; /** * @type {boolean} * @expose */ this.encoded; }
А чтобы избежать обфускации при взаимодействии с другими окнами мы используем так называемые экспортируемые интерфейсы (интерфейсы, у которых все методы являются экспортируемыми).

/** * Экспортируемый интерфейс контрола DropDownWindow * * @interface * @struct */ WebUI.IDropDownWindowExp = function(){} /** * Перемещает выделение на 1 вперед или назад * * @param {boolean} isForward * @param {boolean} checkOnly * @return {boolean} * @expose */ WebUI.IDropDownWindowExp.prototype.moveMarker = function (isForward, checkOnly){} /** * Перемещает выделение в начало или конец * * @param {boolean} isFirst * @param {boolean} checkOnly * @return {boolean} * @expose */ WebUI.IDropDownWindowExp.prototype.moveMarkerTo = function (isFirst, checkOnly){} /** * @return {boolean} * @expose */ WebUI.IDropDownWindowExp.prototype.selectValue = function (){}

We used Virtual DOM before it became mainstream)

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

Оптимизация работы веб-клиента

Чтобы наш веб-клиент работал быстрее, мы по максимуму стараемся задействовать штатные возможности браузера (CSS и т.п.). Так, командная панель формы (расположенная практически на каждой форме приложения) отрисовывается исключительно средствами браузера, динамической версткой на базе CSS.

Тестирование

Для функционального тестирования и тестирования производительности мы используем инструмент собственного производства (написанный на Java и C++), а также набор тестов, построенных на базе Selenium .

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

Инструмент также проводит замеры производительности приложений с точностью до 25 миллисекунд. В ряде случаев мы закольцовываем части сценария (например, несколько раз повторяем ввод заказа) для анализа деградации времени выполнения со временем. Результаты всех замеров записываются в лог для анализа.


Наш инструмент тестирования и тестируемое приложение

Наш инструмент и Selenium дополняют друг друга; например, если какая-то кнопка на одном из экранов поменяла свое местоположение – Selenium это может не отследить, но наш инструмент заметит, т.к. делает попиксельное сравнение скриншота с эталоном. Также инструмент в состоянии отследить проблемы с обработкой ввода с клавиатуры или мыши, так как именно их он и воспроизводит.

Тесты на обоих инструментах (нашем и Selenium) запускают типовые сценарии работы из наших прикладных решений. Тесты автоматически запускаются после ежедневной сборки платформы «1С:Предприятие». В случае замедления работы сценариев (по сравнению с предыдущей сборкой) мы проводим расследование и устраняем причину замедления. Критерий у нас простой – новая сборка должна работать не медленнее предыдущей.

Для расследования инцидентов замедления работы разработчики используют разные инструменты; в основном используется Dynatrace AJAX Edition производства компании DynaTrace . Проводится запись логов выполнения проблемной операции на предыдущей и на новой сборке, затем логи анализируются. При этом время выполнения единичных операций (в миллисекундах) может не быть решающим фактором – в браузере периодически запускаются служебные процессы типа уборки мусора, они могут наложиться на время выполнения функций и исказить картину. Более релевантными параметрами в этом случае будет количество выполненных инструкций JavaScript, количество атомарных операций над DOM и т.п. Если количество инструкций/операций в одном и том же сценарии в новой версии увеличилось – это почти всегда означает падение быстродействия, которое нужно исправлять.

Также одной из причин падения производительности может быть то, что Google Closure Compiler по какой-то причине не смог сделать inline-подстановку функции (например, потому что функция рекурсивная или виртуальная). В этом случае мы стараемся исправить ситуацию, переписав исходный код.

Расширения браузеров

В случае, когда прикладному решению нужна функциональность, которой нет в JavaScript, мы используем расширения браузеров:
  • для работы с файлами
  • для работы с криптографией
  • работа с внешними компонентами
Наши расширения состоят из двух частей. Первая часть – то, что называется расширением браузера (как правило, написанные на JavaScript расширения для Chrome и Firefox), которые взаимодействуют со второй частью - бинарным расширением, реализующим нужную нам функциональность. Надо упомянуть, что мы пишем 3 версии бинарных расширений – под Windows, Linux и MacOS. Бинарное расширение поставляется в составе платформы 1С:Предприятие и находится на сервере приложений 1С. При первом вызове с веб-клиента оно загружается на клиентский компьютер и устанавливается в браузере.

При работе в Safari наши расширения используют NPAPI, при работе в Internet Explorer - технологию ActiveX. Microsoft Edge пока не поддерживает расширения, поэтому веб-клиент в нем работает с ограничениями.

Дальнейшее развитие

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

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

Теги: Добавить метки

Имеется windows-сервер c 1С 8.3 (БД - MSSQL).
Задача - настроить публикацию базы на линуксовом web-сервере.
Тонкости - модуль 1С для апача работает только с 2.0 и 2.2, а текущая версия в большинстве дистрибутивов - 2.4+
Пишется больше для себя, чтобы не забыть. Ну и мало ли, вдруг пригодится еще кому - не придется бегать по форумам в поисках нужных команд.

Железо - дал гигабайт оперативки, одно ядро и 20 гигабайт диска. Увеличить никогда не поздно.
ОС: Debian Stable, привык я к нему.

Ставлю минимум, включая ssh-сервер, но не включая web. К этому еще вернемся.

После установки базовая настройка по вкусу, я обычно ставлю локаль utf8, ставлю sudo, mc и vim, остальное по потребностям.
Дальше надо поставить apache 2.2. Причем сделать это правильным способом, а не просто скачав deb-пакет. :)

Сперва добавляем в /etc/apt/sources.list строчки со ссылкой на предыдущую версию дистрибутива.
deb http://mirror.yandex.ru/debian/ wheezy main deb-src http://mirror.yandex.ru/debian/ wheezy main
Можно, конечно, написать oldstable - в настоящий момент тоже будет правильно. Но только в настоящий, потому рано или поздно выйдет новая стабильная версия и в oldstable и тогда вместо apache 2.2 там будет 2.4. Хотя, надеюсь, к тому времени 1С обновится и заработает с более новыми версиями апача. Но кто их знает? :)
Где mirror.yandex.ru - там пишется имя вашего любимого сервера с репозиторием.

Потом обновляем индексы - apt-get update - и смотрим, что у нас тут есть по apache командой apt-cache showpkg apache2
Там много всего выводится, но нас интересует только начало вывода:
Package: apache2 Versions: 2.4.10-10+deb8u3 (/var/lib/apt/lists/mirror.yandex.ru_debian_dists_stable_main_binary-i386_Packages) Description Language: File: /var/lib/apt/lists/mirror.yandex.ru_debian_dists_stable_main_binary-i386_Packages MD5: Description Language: en File: /var/lib/apt/lists/mirror.yandex.ru_debian_dists_stable_main_i18n_Translation-en MD5: Description Language: ru File: /var/lib/apt/lists/mirror.yandex.ru_debian_dists_stable_main_i18n_Translation-ru MD5: 2.4.10-10+deb8u1 (/var/lib/apt/lists/security.debian.org_dists_stable_updates_main_binary-i386_Packages) Description Language: File: /var/lib/apt/lists/mirror.yandex.ru_debian_dists_stable_main_binary-i386_Packages MD5: Description Language: en File: /var/lib/apt/lists/mirror.yandex.ru_debian_dists_stable_main_i18n_Translation-en MD5: Description Language: ru File: /var/lib/apt/lists/mirror.yandex.ru_debian_dists_stable_main_i18n_Translation-ru MD5: 2.2.22-13+deb7u6 (/var/lib/apt/lists/mirror.yandex.ru_debian_dists_wheezy_main_binary-i386_Packages) Description Language: File: /var/lib/apt/lists/mirror.yandex.ru_debian_dists_wheezy_main_binary-i386_Packages MD5: Description Language: en File: /var/lib/apt/lists/mirror.yandex.ru_debian_dists_wheezy_main_i18n_Translation-en MD5: Description Language: ru File: /var/lib/apt/lists/mirror.yandex.ru_debian_dists_wheezy_main_i18n_Translation-ru MD5:

Видим, что кроме 2.4.10 имеется версия 2.2.22-13+deb7u6 - то, что нужно.
Ставим: apt-get install apache2=2.2.22-13+deb7u6
Или, точнее: apt-get install apache2=2.2.22-13+deb7u6 apache2-mpm-worker=2.2.22-13+deb7u6 apache2.2-common=2.2.22-13+deb7u6 apache2.2-bin=2.2.22-13+deb7u6 , а остальные зависимости уже подтянутся автоматом.

После этого ставим апачей на холд, чтобы не обновить случайно.

Apt-mark hold apache2 apache2-mpm-worker apache2.2-common apache2.2-bin apache2 помечен как зафиксированный. apache2-mpm-worker помечен как зафиксированный. apache2.2-common помечен как зафиксированный. apache2.2-bin помечен как зафиксированный.
Можно запустить service apache2 start и стукнуть телнетом на 80 порт для проверки, если лень браузер запускать.

telnet localhost 80
Trying::1... Connected to localhost. Escape character is "^]". 1 501 Method Not Implemented

Method Not Implemented

1 to /index.html not supported.


Apache/2.2.22 (Debian) Server at 1cweb Port 80
Connection closed by foreign host.

Ругается - значит работает.

Теперь ставим 1С.
Нужны только веб-сервисы 1С (пакет 1c-enterprise83-ws ). И 1c-enterprise83-common , который в зависимостях прописан. И 1c-enterprise83-server , который в зависимостях не прописан, но без него утилита публикации пишет «Ошибка сегментирования».
В принципе, необходим только модуль для апача wsap22.so из пакета 1c-enterprise83-ws , а всё остальное можно через текстовый редактор сделать. Но я человек ленивый и лучше потрачу несколько мегабайт на 1С, чем буду руками вбивать строчки в конфиги. :)

Дальше надо создать папку для хранения настроек опубликованных БД 1С. Можно в дереве вебсервера, но я лучше отдельно сделаю, прямо в корне, /1с.
После этого из папки с установленными файлами 1С (/opt/1C/v8.3/i386 ) запускаем утилиту публикации webinst со следующими параметрами (публикую нашу тестовую базу):
./webinst -apache22 -wsdir testlitupp -dir /1c/testlitupp -connstr "Srvr=10.0.0.4;Ref=testlitupp;" -confPath /etc/apache2/apache2.conf Публикация выполнена

Apache22 - наша версия вебсервера
-wsdir testlitupp - папка на вебсервере, в которой будет доступна опубликованная база (http://вашсервер/testlitupp)
-dir /1c/testlitupp - папка, в которой будет храниться файл default.vrd с настройками публикации
-connstr «Srvr=10.0.0.4;Ref=testlitupp;» - ip сервера 1С и имя публикуемой базы данных
-confPath /etc/apache2/apache2.conf - путь к конфигу apache

Если было написано «Публикация выполнена», значит всё прошло удачно. Если пишет «Ошибка сегментирования», то вы, скорее всего, забыли поставить 1c-enterprise83-server .
По результатам имеем файл default.vrd

И несколько новых строк в файле конфигурации веб-сервера:

LoadModule _1cws_module "/opt/1C/v8.3/i386/wsap22.so" # 1c publication Alias "/testlitupp" "/1c/testlitupp/" AllowOverride All Options None Order allow,deny Allow from all SetHandler 1c-application ManagedApplicationDescriptor "/1c/testlitupp/default.vrd"
Перезапускаем апач (service apache2 restart) и идём смотреть, что там опубликовалось.
Опубликовалось, просит пароль.

И впускает в базу.

Работает. Дополнительные настройки публикации делаются через редактирование vrd-файлов (к примеру, включение отладки), а допиливанием интерфейса веб-клиента должны заниматься ваши программисты 1С.
Если будете дописывать опции, к примеру, с подключением сервисов руками, то не забудьте удалить в файле default.vrd последний слэш в строчке «base="/testlitupp" ib="Srvr=10.0.0.4;Ref=testlitupp;"/ >», я с этим долго возился. Если не удалить и что-то дописать после, то вылетает «ошибка 500» без дополнительной информации.
Какая будет нагрузка на вебсервер - я ещё не знаю, у нас это пока в тестовом режиме работает и хватает выделенных ресурсов. Но добавить памяти или ядер по мере увеличения потребностей проблем не составит.

В целом, в других дистрибутивах linux всё делается аналогично, различия только в способах установки старой версии apache.