À partir de la version de la plate-forme 1C 8.3, il est devenu possible de publier des infobases sur des serveurs Web. Cette décision très pratique, car en cliquant sur le lien dans le navigateur, vous pouvez pleinement travailler en 1C. Attention, le travail n'est possible qu'en mode "Entreprise", vous ne pouvez utiliser le configurateur que sur un client lourd.

Bien sûr, 1C a annoncé sa liste d'exigences pour système opérateur et les navigateurs à partir desquels la connexion sera établie via le serveur Web à 1C. Mais, en pratique, il y a beaucoup plus de possibilités. Par exemple, vous pouvez travailler en 1C via un navigateur standard à partir d'un téléphone mobile.

Dans cet article, nous examinerons étape par étape la publication d'une infobase 1C 8.3 sur un serveur Web utilisant Apache. Les paramètres décrits ci-dessous, que nous effectuerons dans 1C lui-même, ne sont pas différents de la publication sur le serveur Web IIS.

La seule différence est que le serveur exécutant IIS est plus "pointilleux" en termes de paramètres, donc le plus souvent le choix tombe sur Apache.

Installation et configuration d'Apache 2.4

Tout d'abord, vous devez télécharger Apache lui-même, par exemple, à partir du site officiel. Actuel sur ce moment version 2.4. Il n'y a rien de compliqué dans le processus d'installation, il suffit de suivre l'assistant.

Lorsqu'une fenêtre contenant des informations sur le serveur s'affiche lors de l'installation, saisissez "localhost" dans les deux premiers champs. Cela signifiera que notre ordinateur sera le serveur sur lequel se trouve 1C.

Notez également que nous utiliserons le port 80 (le commutateur en bas du formulaire). Il est important qu'il ne soit pas occupé par d'autres applications.

Après une installation réussie du programme, une icône spéciale Apache apparaîtra dans la barre d'état. Avec lui, vous pouvez à la fois démarrer et arrêter le serveur Web.

Publication de la base d'information 1C 8.3

Après Installations d'Apache vous pouvez procéder directement à la publication de l'infobase sur le serveur Web. Pour ce faire, rendez-vous sur socle souhaité en mode configuration. Toutes les actions nécessaires seront effectuées ici. Dans ce cas, comme mentionné ci-dessus, vous pouvez utiliser cette instruction dans le cas de l'utilisation d'IIS.

Sélectionnez "Publier sur le serveur Web" dans le menu "Administration". Dans la fenêtre qui s'ouvre, nous laisserons tous les paramètres par défaut, en n'en modifiant qu'une petite partie.

En tant que serveur Web, nous sélectionnerons Apache 2.2, que nous avons installé précédemment. Le nom peut être une valeur arbitraire. Nous publions 1C: Document Management, nous l'appellerons donc simplement "doc". Dans le champ du répertoire, nous sélectionnerons également le dossier vide que nous avons créé, qui peut être situé n'importe où.

Après avoir saisi toutes les données nécessaires, cliquez sur le bouton "Publier" et redémarrez le serveur web Apache.

Maintenant en barre d'adresse navigateur, entrez "localhost/doc". Nous avons une fenêtre d'autorisation en 1C.

Après avoir entré un identifiant avec un mot de passe et une authentification, le 1C familier s'ouvrira devant nous.

31/05/2016

Configuration du serveur Web Microsoft Internet Information Services (IIS) pour qu'il fonctionne avec les plateformes 1C:Enterprise

Informations générales sur les publications

Comme vous le savez, la publication de bases de données 1C peut être effectuée à la fois à partir du configurateur et à l'aide de l'utilitaire webinst. L'algorithme de publication est décrit plus en détail sur l'ITS, par exemple, sur ce lien.

Il convient de noter que la publication pour un serveur 64 bits n'est possible qu'à partir du configurateur sous Linux OS ou à l'aide de l'utilitaire webinst. Dans certains de nos tests de charge, les serveurs Web IIS 64 bits ont montré un léger meilleure performance, par conséquent, en l'absence d'autres restrictions, nous vous recommandons de les utiliser.

Si vous envisagez d'utiliser un serveur Web IIS 32 bits, n'oubliez pas d'autoriser l'exécution des applications 32 bits : dans la liste "Pools d'applications", pour chaque pool dont vous avez besoin, faites un clic droit, dans menu contextuel choisir " Options supplémentaires… » (« Paramètres avancés »), puis réglez le paramètre « Activer les applications 32 bits » sur « Vrai ».

La documentation décrit également plusieurs points importants concernant l'utilisation du serveur Web IIS. Pour les citer, lors de la publication sur un serveur Web IIS, n'oubliez pas que :

• La publication est toujours effectuée sur le site Web par défaut.
• La publication est toujours effectuée dans le pool d'applications par défaut (DefaultAppPool).
• La prise en charge de .NET doit être désactivée pour le pool d'applications utilisé pour le fonctionnement 1C:Enterprise. Pour ce faire, définissez la propriété du pool d'applications "Versions d'environnement. NET Framework» (« Version .NET Framework ») à « Aucun code géré ».

L'information sur les deux premiers points est importante en soi, et surtout dans le contexte de la question à l'étude, car elle nous sera utile à l'avenir. La troisième recommandation, d'après notre expérience, n'est pas obligatoire et le serveur Web IIS fonctionne correctement en mode d'utilisation de version, par exemple, .NET Framework v4.

Configuration d'IIS pour différentes versions de la plate-forme 1C

Pour utiliser plusieurs plug-ins de serveur Web qui ne diffèrent que par les troisième et quatrième chiffres de la version, vous devez utiliser différents pools d'applications (ce n'est pas possible dans le même pool d'applications). Ainsi, il faut créer autant de pools d'applications dans le serveur web que de versions différentes de plug-ins à utiliser, puis chaque application virtuelle doit être associée manuellement au pool d'applications souhaité.

Ainsi, par exemple, créons deux pools d'applications supplémentaires par exemple (dans le cas général, il peut y en avoir plus), pour plus de commodité, indiquons dans le nom du pool la version de la plate-forme avec laquelle nous prévoyons de les utiliser (nous avons indiqué la version sous forme abrégée - "8.3.6", mais il peut être plus pratique pour vous d'utiliser version complète, par exemple, "8.3.6.2237", ou divisent généralement les pools d'applications par application, par exemple, "test cluster pool"). Définissez les paramètres recommandés (version de l'environnement, signe d'utilisation d'applications 32 bits). Par conséquent, vous devriez voir la liste suivante de pools d'applications de serveur Web IIS :

Ensuite, lancez le configurateur (n'oubliez pas d'effectuer cette action au nom de l'administrateur) et effectuez la publication. Comme indiqué dans la documentation, il existe (ou est mis à jour si la publication a déjà été effectuée auparavant) une entrée concernant le nouveau site dans le groupe "Site Web par défaut". Les paramètres avancés de cette publication répertorient le pool d'applications par défaut, "DefaultAppPool". Pour le modifier, vous pouvez appeler la boîte de dialogue "Options avancées ..." ou "Paramètres de base ...". Nous appelons les principaux :

Nous remplaçons le pool d'applications par défaut (« DefaultAppPool ») par le pool d'applications correspondant à la version de la plateforme 1C de la base publiée (« AppPool 1C 8.3.6 » ou « AppPool 1C 8.3.7 »).

Si vous avez besoin de changer le gestionnaire d'extension du serveur Web (par exemple, après avoir publié depuis le configurateur de la version 32 bits à la version 64 bits), vous pouvez le faire ici :

Nous faisons de même pour une autre infobase et une autre version de la plateforme 1C.

C'est tout paramètres nécessaires complété! Nous vérifions et apprécions le travail simultané avec les applications Web 1C différentes versions au sein d'un serveur Web :

Conclusion

Dans cet article, nous avons décrit une méthode qui vous permet d'utiliser plusieurs publications d'infobase au sein d'un même serveur Web IIS pour les infobases 1C:Enterprise de différentes versions. Ceci est nécessaire si vous travaillez sur un serveur avec plusieurs bases de données de travail ou de test pour lesquelles les versions de la plateforme 1C utilisées diffèrent.

Nous espérons que vous pourrez facilement accomplir la tâche dont vous avez besoin et continuer à utiliser les produits 1C avec plaisir. Eh bien, si quelque chose ne fonctionne pas pour vous, ou si vous rencontrez des difficultés, nous vous aiderons certainement !

L'une des caractéristiques intéressantes de la technologie 1C:Enterprise est que la solution d'application développée à l'aide de la technologie formulaires gérés, peut être exécuté aussi bien en client léger (exécutable) sous Windows, Linux, MacOS X, qu'en client web pour 5 navigateurs - Chrome, Internet Explorer, Firefox, Safari, Edge, et tout cela sans changer le code source de l'application. De plus, extérieurement, l'application dans le client léger et dans le navigateur fonctionne et semble presque identique.
Trouvez 10 différences (sous la coupe 2 images):

Fenêtre client léger sous linux :

La même fenêtre dans le client Web (dans le navigateur Chrome) :

Pourquoi avons-nous créé un client Web ? Parlant quelque peu pathétiquement, le temps nous a confié une telle tâche. Depuis longtemps, le travail sur Internet est devenu un pré-requis pour les applications métiers. Tout d'abord, nous avons ajouté la possibilité de travailler via Internet pour notre client léger (certains de nos concurrents s'y sont d'ailleurs arrêtés ; d'autres au contraire ont abandonné le client léger et se sont limités à la mise en place du client web). Nous avons décidé de donner à nos utilisateurs la possibilité de choisir l'option client qui leur convient le mieux.

L'ajout de fonctionnalités Web au client léger était une entreprise de grande envergure, avec un changement complet de l'architecture client/serveur. La création d'un client Web est un tout nouveau projet qui a commencé à partir de zéro.

Formulation du problème

Donc, les pré-requis pour le projet : le client web doit faire la même chose que le client léger, à savoir :

1. Afficher l'interface utilisateur
2. Exécuter le code client écrit en langage 1C

L'interface utilisateur en 1C est décrite dans un éditeur visuel, mais de manière déclarative, sans disposition pixel par pixel des éléments ; environ trois douzaines de types d'éléments d'interface sont utilisés - boutons, champs de saisie (texte, numérique, date / heure), listes, tableaux, graphiques, etc.

Le code client en langage 1C peut contenir des appels au serveur, travailler avec des ressources locales (fichiers, etc.), imprimer, et bien plus encore.

Le client léger (lorsqu'il travaille via le Web) et le client Web utilisent le même ensemble de services Web pour communiquer avec le serveur d'applications 1C. La mise en œuvre des clients, bien sûr, est différente - le client léger est écrit en C ++, le client Web est écrit en JavaScript.

Un peu d'histoire

Le projet client web a débuté en 2006 avec une équipe (moyenne) de 5 personnes. A certaines étapes du projet, des développeurs ont été impliqués pour implémenter des fonctionnalités spécifiques ( feuille de calcul, schémas, etc.) ; en règle générale, ce sont les mêmes développeurs qui ont créé cette fonctionnalité dans le client léger. Ceux. les développeurs ont réécrit des composants en JavaScript qu'ils avaient précédemment créés en C++.

Dès le début, nous avons rejeté l'idée de toute conversion automatique (au moins partielle) du code C++ du client léger vers le JavaScript du client Web en raison des fortes différences conceptuelles entre les deux langages ; le client Web a été écrit en JavaScript à partir de zéro.

Dans les premières itérations du projet, le client Web a converti le code client dans le langage 1C intégré directement en JavaScript. Le client léger agit différemment - le code dans le langage 1C intégré est compilé en bytecode, puis ce bytecode est interprété sur le client. Par la suite, le client Web a commencé à faire de même - d'une part, il a donné un gain de performances, et d'autre part, il a permis d'unifier l'architecture des clients légers et Web.

La première version de la plate-forme 1C:Enterprise avec prise en charge du client Web a été publiée en 2009. Le client Web à l'époque prenait en charge 2 navigateurs - Internet Explorer et Firefox. Les plans initiaux étaient de prendre en charge Opera, mais en raison de problèmes insurmontables avec les gestionnaires de fermeture d'application dans Opera à ce moment-là (il n'était pas possible de suivre avec une certitude à 100% que l'application se fermait, et à ce moment-là d'effectuer la procédure de déconnexion du serveur d'application 1C), ces plans ont dû être abandonnés.

Structuration du projet

Au total, la plateforme 1C:Enterprise compte 4 projets écrits en JavaScript :

1. Les WebTools sont des bibliothèques partagées utilisées par d'autres projets (nous incluons également la Google Closure Library ici).
2. Contrôle FormattedDocumentFormatedDocument control
3. Contrôle du planificateur (implémenté en JavaScript dans le client léger et le client Web)
4. Client Web

La structure de chaque projet ressemble à la structure des projets Java (ou des projets .NET - selon ce qui est le plus proche de vous) ; nous avons des espaces de noms, et chaque espace de noms se trouve dans dossier séparé. À l'intérieur du dossier se trouvent des fichiers et des classes d'espace de noms. Il y a environ 1000 fichiers dans le projet client Web.

Structurellement, le client Web est largement divisé en sous-systèmes suivants :

• Interface d'application cliente gérée
  • Interface générale de l'application (menus système, panneaux)
  • Interface de formulaires gérés, qui comprend, entre autres, une trentaine de contrôles (boutons, Divers types champs de saisie - texte, numérique, date/heure, etc., tableaux, listes, graphiques, etc.)
• Modèle objet disponible pour les développeurs sur le client (plus de 400 types au total : modèle objet d'interface managée, paramètres de composition des données, mise en forme conditionnelle, etc.)
• Interprète de langue intégré 1C
• Extensions de navigateur (utilisées pour les fonctionnalités non prises en charge dans JavaScript)
  • Travailler avec la cryptographie
  • Travailler avec des fichiers
  • Technologie composants externes, leur permettant d'être utilisés à la fois dans les clients légers et Web

Fonctionnalités de développement

Implémenter tout ce qui précède en JavaScript n'est pas une tâche facile. Le client Web 1C est peut-être l'une des plus grandes applications côté client écrites en JavaScript - environ 450 000 lignes. Nous utilisons activement une approche orientée objet dans le code du client Web, ce qui simplifie le travail avec un projet aussi important.

Pour minimiser la taille du code client, nous avons d'abord utilisé notre propre obfuscateur, et à partir de la version 8.3.6 de la plateforme (octobre 2014), nous avons commencé à utiliser le Google Closure Compiler . L'effet de l'utilisation en nombre est la taille de l'infrastructure du client Web après obfuscation :

• Propre obfuscateur - 1556 ko
• Compilateur de fermeture Google - 1073 ko

L'utilisation de Google Closure Compiler nous a permis d'améliorer les performances du client Web de 30 % par rapport à notre propre obfuscateur. De plus, la quantité de mémoire consommée par l'application a diminué de 15 à 25 % (selon le navigateur).

Google Closure Compiler fonctionne très bien avec du code orienté objet, son efficacité est donc la plus élevée pour un client Web. Le Closure Compiler fait quelques bonnes choses pour nous :

• Vérification de type statique au stade de la construction du projet (fournie par le fait que nous couvrons le code avec des annotations JSDoc). Le résultat est un typage statique, de niveau très proche du typage en C++. Cela permet de détecter un pourcentage assez important d'erreurs au stade de la compilation du projet.
• Réduction de la taille du code par obfuscation
• Un certain nombre d'optimisations du code exécutable, par exemple, telles que :
  • substitutions de fonctions en ligne. L'appel d'une fonction en JavaScript est une opération assez coûteuse, et les substitutions en ligne de petites méthodes fréquemment utilisées peuvent considérablement accélérer le code.
  • Comptage des constantes au moment de la compilation. Si l'expression dépend d'une constante, elle sera remplacée par la valeur réelle de la constante

Nous utilisons WebStorm comme environnement de développement de client Web.

Pour l'analyse de code, nous utilisons SonarQube, où nous intégrons des analyseurs de code statiques. Avec l'aide d'analyseurs, nous surveillons la dégradation de la qualité du code source JavaScript et essayons de l'empêcher.

Quelles tâches avons-nous/résolvons-nous ?

Au cours de la mise en œuvre du projet, nous avons été confrontés à un certain nombre de tâches intéressantes que nous avons dû résoudre.

Echange de données avec le serveur et entre fenêtres

Il existe des situations où l'obscurcissement du code source peut interférer avec le fonctionnement du système. Le code externe au code exécutable du client Web, en raison de l'obscurcissement, peut avoir des noms de fonctions et de paramètres qui diffèrent de ceux attendus par notre code exécutable. Le code externe pour nous est :

• Code provenant du serveur sous forme de structures de données
• Code pour une autre fenêtre d'application

Pour éviter toute confusion lors de l'interaction avec le serveur, nous utilisons la balise @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) * @ex pose */ this. encodé ; )
Et pour éviter l'obscurcissement lors de l'interaction avec d'autres fenêtres, nous utilisons les interfaces dites exportées (interfaces dans lesquelles toutes les méthodes sont exportées).

/** * Interface exportée du contrôle DropDownWindow * * @interface * @struct */ WebUI.IDropDownWindowExp = function()() /** * Avance ou recule la sélection de 1 * * @param (boolean) isForward * @param (boolean) checkOnly * @return (boolean) * @expose */ WebUI.IDropDownWindowExp.prototype.moveMarker = function (isForward, checkOn ly)() /** * Déplace la sélection au début ou à la fin * * @param (boolean) isFirst * @param (boolean) checkOnly * @return (boolean) * @expose */ WebUI.IDropDownWindowExp.prototype.moveMarkerTo = function (isFirst, checkOnly)() /** * @return (boolean) * @expose */ WebUI.IDropDownWindowExp.prototype.selectValue = fonction ()()

Nous avons utilisé Virtual DOM avant qu'il ne devienne courant)

Comme tous les développeurs confrontés à des Web UI complexes, nous nous sommes vite rendu compte que le DOM n'est pas bien adapté aux interfaces utilisateur dynamiques. Presque immédiatement, un analogue du DOM virtuel a été implémenté pour optimiser le travail avec l'interface utilisateur. Pendant le traitement des événements, toutes les modifications DOM sont stockées en mémoire et, uniquement lorsque toutes les opérations sont terminées, les modifications accumulées sont appliquées à l'arborescence DOM.

Optimisation des clients Web

Pour que notre client Web fonctionne plus rapidement, nous essayons d'utiliser au maximum les fonctionnalités standard du navigateur (CSS, etc.). Ainsi, la barre de commandes du formulaire (située sur presque tous les formulaires de candidature) est dessinée exclusivement par le navigateur, mise en page dynamique basée sur CSS.

Essai

Pour les tests fonctionnels et de performance, nous utilisons un outil propriétaire (écrit en Java et C++) et une suite de tests construits sur Selenium.

Notre outil est universel - il vous permet de tester presque n'importe quel programme de fenêtre, et convient donc pour tester à la fois un client léger et un client Web. L'outil enregistre les actions de l'utilisateur qui a lancé la solution d'application 1C dans un fichier de script. Dans le même temps, des images de la zone de travail de l'écran - références - sont enregistrées. Lors de la surveillance de nouvelles versions du client Web, les scénarios sont joués sans la participation de l'utilisateur. Dans les cas où la capture d'écran ne correspond à la référence à aucune étape, le test est considéré comme ayant échoué, après quoi le spécialiste de la qualité mène une enquête - s'agit-il d'une erreur ou d'un changement prévu dans le comportement du système. En cas de comportement planifié, les normes sont automatiquement remplacées par de nouvelles.

L'outil mesure également les performances des applications avec une précision de 25 millisecondes. Dans certains cas, on boucle des parties du script (par exemple, répéter plusieurs fois la saisie de la commande) pour analyser la dégradation du temps d'exécution dans le temps. Les résultats de toutes les mesures sont enregistrés dans un journal pour analyse.

Notre outil de test et application en test

Notre outil et Selenium se complètent ; par exemple, si un bouton sur l'un des écrans a changé d'emplacement - Selenium peut ne pas le suivre, mais notre outil le remarquera, car fait une comparaison pixel par pixel de la capture d'écran avec la norme. De plus, l'outil est capable de détecter les problèmes de traitement des entrées du clavier ou de la souris, car c'est ce qu'il reproduit.

Les tests sur les deux outils (le nôtre et Selenium) exécutent des scénarios de travail typiques de nos solutions applicatives. Les tests sont automatiquement lancés après la construction quotidienne de la plateforme 1C:Enterprise. Si les scripts ralentissent (par rapport à la version précédente), nous enquêterons et corrigerons la cause du ralentissement. Notre critère est simple - le nouvel assemblage ne doit pas fonctionner plus lentement que le précédent.

Les développeurs utilisent différents outils pour enquêter sur les incidents de ralentissement ; principalement utilisé est Dynatrace AJAX Edition de DynaTrace. Les logs de l'exécution de l'opération problématique sur le précédent et sur le nouveau montage sont enregistrés, puis les logs sont analysés. Dans le même temps, le temps d'exécution d'opérations uniques (en millisecondes) peut ne pas être un facteur décisif - des processus de service tels que la récupération de place sont périodiquement lancés dans le navigateur, ils peuvent se chevaucher avec le temps d'exécution des fonctions et déformer l'image. Des paramètres plus pertinents dans ce cas seraient le nombre d'instructions JavaScript exécutées, le nombre d'opérations atomiques sur le DOM, etc. Si le nombre d'instructions/opérations dans le même scénario dans nouvelle version augmenté - cela signifie presque toujours une baisse des performances qui doit être corrigée.

En outre, l'une des raisons de la baisse des performances peut être que le compilateur de fermeture de Google, pour une raison quelconque, n'a pas pu effectuer de substitution en ligne de la fonction (par exemple, parce que la fonction est récursive ou virtuelle). Dans ce cas, nous essayons de remédier à la situation en réécrivant le code source.

Extensions de navigateur

Dans le cas où une solution appliquée nécessite une fonctionnalité qui n'est pas en JavaScript, nous utilisons des extensions de navigateur :

• travailler avec des fichiers
• travailler avec la cryptographie
• travailler avec des composants externes

Nos extensions se composent de deux parties. La première partie est ce qu'on appelle une extension de navigateur (généralement des extensions JavaScript pour Chrome et Firefox) qui interagissent avec la deuxième partie, une extension binaire qui implémente la fonctionnalité dont nous avons besoin. Il convient de mentionner que nous écrivons 3 versions d'extensions binaires - pour Windows, Linux et MacOS. L'extension binaire est fournie dans le cadre de la plate-forme 1C:Enterprise et se trouve sur le serveur d'application 1C. La première fois qu'il est appelé depuis le client Web, il est téléchargé sur l'ordinateur client et installé dans le navigateur.

Lorsque vous travaillez dans Safari, nos extensions utilisent NPAPI, lorsque vous travaillez dans Internet Explorer - technologie ActiveX. Microsoft Edge ne prend pas encore en charge les extensions, le client Web fonctionne donc avec des limitations.

La poursuite du développement

L'un des groupes de travail de l'équipe de développement du client Web est la poursuite du développement Fonctionnalité. La fonctionnalité du client Web doit être identique à la fonctionnalité du client léger, toutes les nouvelles fonctionnalités sont implémentées simultanément dans le client léger et le client Web.

Les autres tâches sont le développement de l'architecture, la refactorisation, l'amélioration des performances et de la fiabilité. Par exemple, l'une des directions est la poursuite de l'évolution vers un modèle de travail asynchrone. Une partie des fonctionnalités du client Web repose actuellement sur un modèle d'interaction synchrone avec le serveur. Le modèle asynchrone gagne désormais en pertinence dans les navigateurs (et pas seulement dans les navigateurs), ce qui oblige à modifier le client web en remplaçant les appels synchrones par des appels asynchrones (et refactoriser le code en conséquence). La transition progressive vers un modèle asynchrone s'explique par la nécessité de prendre en charge les solutions publiées et de les adapter progressivement.

Balises : Ajouter des balises

Il existe un serveur Windows avec 1C 8.3 (DB - MSSQL).
La tâche consiste à mettre en place la publication de la base de données sur un serveur Web Linux.
Subtilités - le module 1C pour Apache ne fonctionne qu'avec 2.0 et 2.2, et Version actuelle dans la plupart des distributions - 2.4+
J'écris plus pour moi, pour ne pas oublier. Eh bien, on ne sait jamais, tout à coup quelqu'un d'autre vous sera utile - vous n'avez pas à parcourir les forums à la recherche des bonnes commandes.

Iron - a donné un gigaoctet de RAM, un cœur et 20 gigaoctets de disque. Il n'est jamais trop tard pour se développer.
OS : Debian Stable, j'y suis habitué.

J'ai défini le minimum, y compris le serveur ssh, mais pas le web. Revenons à cela.

Après l'installation configuration de base au goût, je règle généralement les paramètres régionaux sur utf8, mets sudo, mc et vim, le reste au besoin.
Ensuite, vous devez installer apache 2.2. Et fais-le le droit chemin plutôt que de simplement télécharger le paquet deb. :)

Tout d'abord, ajoutez des lignes à /etc/apt/sources.list avec un lien vers la version précédente distribution.
deb http://mirror.yandex.ru/debian/ wheezy main deb-src http://mirror.yandex.ru/debian/ wheezy main
Vous pouvez bien sûr écrire vieille écurie- pour le moment, aussi, sera correct. Mais seulement dans le vrai, car tôt ou tard une nouvelle version stable sortira et dans vieille écurie puis au lieu d'apache 2.2 il y aura 2.4. Bien que, j'espère, d'ici là, 1C sera mis à jour et fonctionnera avec les nouvelles versions d'Apache. Mais qui sait? :)
Où miroir.yandex.ru- le nom de votre serveur favori avec le référentiel y est écrit.

Ensuite, nous mettons à jour les index - apt-obtenir la mise à jour- et voir ce que nous avons ici pour apache avec la commande apt-cache showpkg apache2
Il y a beaucoup de sortie, mais nous ne sommes intéressés que par le début de la sortie :
Paquet : apache2 Versions : 2.4.10-10+deb8u3 (/var/lib/apt/lists/mirror.yandex.ru_debian_dists_stable_main_binary-i386_Packages) Langue de description : en Fichier : /var/lib/apt/lists/mirror.yandex.ru_debian_dists_stable_main_i18n_Translation-en MD5 : Langue de description : en Fichier : /var/lib/apt/lists/mirror.yandex.ru_debian_dists_stable_main_i18n_Translation-en MD5 : 2.4.10-10+deb8u1 (/var/ Langage de description : Fichier : /var/lib/apt/lists/mirror.yandex.ru_debian_dists_stable_main_binary-i386_Packages MD5 : Langage de description : en Fichier : /var/lib/ apt/lists/mirror.yandex.ru_debian_d ists_stable_main_i18n_Translation-en MD5 : Langue de description : ru Fichier : /var/lib/apt/lists/mirror.yandex.ru_debian_dists_stable_main_i18n_Translation-en MD5 : 2.2.22-13+deb7u6 (/var/lib/apt/lists/mirror.yandex .ru_debian_dists_wheezy_main_binary-i386_Packages) Langue de description : Fichier : /var/lib/apt/lists/mirror.yandex.ru_debian_dists_wheezy_main_binary-i386_Packages MD5 : Langue de description : en Fichier : /var/lib/apt/lists/mirror.yandex.ru_debian_dists_wheezy_main_i18n_Translation -en MD5 : Langue de description : en Fichier : /var/lib/apt/lists/mirror.yandex.ru_debian_dists_wheezy_main_i18n_Translation-ru MD5 :

Nous voyons qu'en plus de 2.4.10, il existe la version 2.2.22-13+deb7u6 - ce dont vous avez besoin.
Nous mettons: apt-get install apache2=2.2.22-13+deb7u6
Ou plus précisément : 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, et le reste des dépendances sera automatiquement extrait.

Après cela, nous avons mis l'Apache en attente pour ne pas le mettre à jour par accident.

Apt-mark hold apache2 apache2-mpm-worker apache2.2-common apache2.2-bin apache2 est marqué comme validé. apache2-mpm-worker est marqué comme engagé. apache2.2-common est marqué comme validé. apache2.2-bin est marqué comme commité.
Vous pouvez exécuter le service apache2 start et telnet sur le port 80 pour vérifier si vous êtes trop paresseux pour lancer le navigateur.

hôte local telnet 80
Essayer :: 1... Connecté à localhost. Le caractère d'échappement est "^]". 1

Méthode non implémentée

1 à /index.html non pris en charge.

---

Serveur Apache/2.2.22 (Debian) au port 1cweb 80

Connexion fermée par hôte étranger.

Jure - cela signifie que cela fonctionne.

Maintenant, nous mettons 1C.
Seuls les services Web 1C sont nécessaires (package 1c-entreprise83-ws). ET 1c-entreprise83-commun, qui est enregistré dans les dépendances. ET 1c-enterprise83-server, qui n'est pas spécifié dans les dépendances, mais sans lui, l'utilitaire de publication écrit "Erreur de segmentation".
En principe, seul le module pour Apache est nécessaire wsap22.so du paquet 1c-entreprise83-ws, et tout le reste peut passer éditeur de texte faire. Mais je suis une personne paresseuse et je préfère dépenser quelques mégaoctets sur 1C plutôt que de conduire manuellement des lignes dans des configurations. :)

Ensuite, vous devez créer un dossier pour stocker les paramètres de la base de données publiée 1C. C'est possible dans l'arborescence du serveur web, mais je ferais mieux de le faire séparément, directement à la racine, / 1s.
Après cela, à partir du dossier avec fichiers installés 1C ( /opt/1C/v8.3/i386) exécutez l'utilitaire de publication webinst avec les paramètres suivants (je publie notre base de données de test) :
./webinst -apache22 -wsdir testlitupp -dir /1c/testlitupp -connstr "Srvr=10.0.0.4;Ref=testlitupp;" -confPath /etc/apache2/apache2.conf Publié

Apache22 - notre version du serveur Web
-wsdir testlitupp - dossier sur le serveur Web où la base de données publiée sera disponible (http://yourserver/testlitupp)
-dir /1c/testlitupp - dossier où le fichier default.vrd avec les paramètres de publication sera stocké
-connstr "Srvr=10.0.0.4;Ref=testlitupp;" - IP du serveur 1C et nom de la base de données publiée
-confPath /etc/apache2/apache2.conf - chemin vers la configuration apache

S'il indique "Publié", alors tout s'est bien passé. S'il indique "Erreur de segmentation", vous avez probablement oublié de mettre 1c-enterprise83-server.
Sur la base des résultats, nous avons le fichier default.vrd

Et quelques nouvelles lignes dans le fichier de configuration du serveur Web :

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"
On redémarre Apache (service apache2 restart) et on va voir ce qui y a été publié.
Publié, demande un mot de passe.

Et laissez-le entrer dans la base.

Travaux. Des paramètres de publication supplémentaires sont définis en modifiant les fichiers vrd (par exemple, en activant le débogage), et vos programmeurs 1C doivent être impliqués dans la finition de l'interface du client Web.
Si vous ajoutez des options, par exemple, avec la connexion manuelle des services, n'oubliez pas de supprimer la dernière barre oblique de la ligne "base="/testlitupp" ib="Srvr=10.0.0.4;Ref=testlitupp;" dans le fichier default.vrd / >", j'ai tripoté ça pendant longtemps. Si vous ne supprimez pas et n'ajoutez rien après, une "erreur 500" s'envole sans informations supplémentaires.
Quelle sera la charge sur le serveur Web - je ne sais pas encore, cela fonctionne toujours en mode test pour nous et il y a suffisamment de ressources allouées. Mais ajouter de la mémoire ou des cœurs à mesure que les besoins augmentent ne pose aucun problème.

En général, dans d'autres distributions Linux tout se fait de la même manière, les différences ne sont que dans les méthodes d'installation ancienne version apache.