A partire dalla versione della piattaforma 1C 8.3, è diventato possibile pubblicare infobase su server web. Questa soluzione molto comodo, perché cliccando sul link nel browser, puoi lavorare completamente in 1C. Si prega di notare che il lavoro è possibile solo in modalità "Enterprise" È possibile utilizzare il configuratore solo su un thick client.

Ovviamente, 1C ha annunciato il suo elenco di requisiti per sistema operativo e browser da cui verrà effettuata la connessione tramite il server Web a 1C. Ma, in pratica, ci sono molte più possibilità. Ad esempio, puoi lavorare in 1C tramite un normale browser da un telefono cellulare.

In questo articolo, esamineremo passo dopo passo la pubblicazione di un'infobase 1C 8.3 su un server Web utilizzando Apache. Le impostazioni descritte di seguito, che realizzeremo in 1C stesso, non sono diverse dalla pubblicazione sul server Web IIS.

L'unica differenza è che il server che esegue IIS è più "schizzinoso" in termini di impostazioni, quindi molto spesso la scelta ricade su Apache.

Installazione e configurazione di Apache 2.4

Prima di tutto, devi scaricare Apache stesso, ad esempio, dal sito Web ufficiale. Corrente attiva questo momento versione 2.4. Non c'è niente di complicato nel processo di installazione, basta seguire l'assistente.

Quando vedi una finestra con informazioni sul server durante l'installazione, inserisci "localhost" nei primi due campi. Ciò significa che il nostro computer sarà il server su cui si trova 1C.

Si noti inoltre che utilizzeremo la porta 80 (l'interruttore nella parte inferiore del modulo). È importante che non sia occupato da altre applicazioni.

Dopo aver installato correttamente il programma, nella barra delle applicazioni verrà visualizzata un'icona speciale di Apache. Con esso, puoi sia avviare che arrestare il server web.

Pubblicazione della banca dati 1C 8.3

Dopo Installazioni Apache puoi procedere direttamente alla pubblicazione dell'infobase sul web server. Per fare questo, vai a fondo desiderato in modalità configurazione. Tutte le azioni necessarie verranno eseguite qui. In questo caso, come accennato in precedenza, è possibile utilizzare questa istruzione in caso di utilizzo di IIS.

Selezionare "Pubblica su server Web" dal menu "Amministrazione". Nella finestra che si apre lasceremo tutte le impostazioni predefinite, modificandone solo una piccola parte.

Come server web, selezioneremo Apache 2.2, che abbiamo installato in precedenza. Il nome può essere un valore arbitrario. Pubblichiamo 1C: Document Management, quindi lo chiameremo semplicemente "doc". Nel campo della directory, selezioneremo anche la cartella vuota che abbiamo creato, che può trovarsi ovunque.

Dopo aver inserito tutti i dati necessari, cliccare sul pulsante "Pubblica" e riavviare il web server Apache.

Ora in barra degli indirizzi browser, inserisci "localhost/doc". Abbiamo una finestra di autorizzazione in 1C.

Dopo aver inserito un login con password e autenticazione, il familiare 1C si aprirà davanti a noi.

31/05/2016

Configurazione del server Web Microsoft Internet Information Services (IIS) per l'utilizzo con piattaforme 1C:Enterprise

Informazioni generali sulle pubblicazioni

Come sapete, la pubblicazione dei database 1C può essere effettuata sia dal configuratore che utilizzando l'utility webinst. L'algoritmo di pubblicazione è descritto più dettagliatamente sull'ITS, ad esempio, a questo link.

Vale la pena notare che la pubblicazione per un server a 64 bit è possibile solo dal configuratore nel sistema operativo Linux o utilizzando l'utilità webinst. In alcuni dei nostri test di carico, i server web IIS a 64 bit si sono dimostrati leggermente prestazioni migliori, pertanto, in assenza di altre restrizioni, si consiglia di utilizzarli.

Se prevedi di utilizzare un server Web IIS a 32 bit, non dimenticare di consentire l'esecuzione delle applicazioni a 32 bit: nell'elenco "Pool di applicazioni", per ogni pool necessario, fai clic con il pulsante destro del mouse, in menù contestuale scegliere " Opzioni aggiuntive…” (“Impostazioni avanzate”), quindi impostare il parametro “Abilita applicazioni a 32 bit” su “True”.

La documentazione descrive anche diversi punti importanti relativi al lavoro con il server Web IIS. Per citarli, quando pubblichi su un server web IIS, ricorda che:

• La pubblicazione viene sempre eseguita sul sito Web predefinito.
• La pubblicazione viene sempre eseguita nel pool di applicazioni predefinito (DefaultAppPool).
• Il supporto .NET deve essere disabilitato per il pool di applicazioni utilizzato per l'operazione 1C:Enterprise. Per fare ciò, impostare la proprietà del pool di applicazioni "Environment Versions. NET Framework” (“Versione .NET Framework”) a “Nessun codice gestito”.

L'informazione sui primi due punti è importante di per sé, e soprattutto nel contesto della questione in esame, in quanto ci sarà utile in futuro. La terza raccomandazione, nella nostra esperienza, non è obbligatoria e il server Web IIS funziona correttamente in modalità di utilizzo della versione, ad esempio .NET Framework v4.

Configurazione di IIS per diverse versioni della piattaforma 1C

Per utilizzare più plug-in del server Web che differiscono solo per la terza e la quarta cifra della versione, è necessario utilizzare diversi pool di applicazioni (questo non è possibile all'interno dello stesso pool di applicazioni). Di conseguenza, nel server Web devono essere creati tanti pool di applicazioni quante sono le diverse versioni di plug-in pianificate da utilizzare, quindi ogni applicazione virtuale deve essere associata manualmente al pool di applicazioni desiderato.

Quindi, ad esempio, creiamo ad esempio due pool di applicazioni aggiuntivi (nel caso generale potrebbero essercene di più), per comodità indichiamo nel nome del pool la versione della piattaforma con cui intendiamo utilizzarli (abbiamo indicato la versione in forma abbreviata - "8.3.6", ma potrebbe essere più comoda da usare versione completa, ad esempio "8.3.6.2237" o in generale dividere i pool di applicazioni per applicazione, ad esempio "test cluster pool"). Impostare i parametri consigliati (versione dell'ambiente, segno dell'utilizzo di applicazioni a 32 bit). Di conseguenza, dovresti vedere il seguente elenco di pool di applicazioni del server Web IIS:

Successivamente, esegui il configuratore (non dimenticare di eseguire questa azione per conto dell'amministratore) ed esegui la pubblicazione. Come indicato nella documentazione, esiste (o viene aggiornato se la pubblicazione è già stata effettuata in precedenza) una voce relativa al nuovo sito nel gruppo "Sito Web predefinito". Le impostazioni avanzate per questa pubblicazione elencheranno il pool di applicazioni predefinito, "DefaultAppPool". Per cambiarlo, puoi chiamare la finestra di dialogo "Opzioni avanzate ..." o "Impostazioni di base ...". Chiamiamo i principali:

Sostituiamo il pool di applicazioni predefinito ("DefaultAppPool") con il pool di applicazioni corrispondente alla versione della piattaforma 1C della base pubblicata ("AppPool 1C 8.3.6" o "AppPool 1C 8.3.7").

Se hai bisogno di cambiare il gestore dell'estensione del server web (ad esempio, dopo aver pubblicato dal configuratore dalla versione a 32 bit alla versione a 64 bit), puoi farlo qui:

Facciamo lo stesso per un'altra infobase e un'altra versione della piattaforma 1C.

È tutto impostazioni necessarie completato! Controlliamo e godiamo del lavoro simultaneo con le applicazioni Web 1C diverse versioni all'interno di un server web:

Conclusione

In questo articolo, abbiamo descritto un metodo che consente di utilizzare diverse pubblicazioni infobase all'interno di un singolo server Web IIS per infobase 1C:Enterprise di versioni diverse. Ciò è necessario se si lavora su un server con diversi database funzionanti o di test per i quali le versioni della piattaforma 1C utilizzate differiscono.

Ci auguriamo che tu possa completare facilmente l'attività di cui hai bisogno e continuare a utilizzare i prodotti 1C con piacere. Bene, se qualcosa non funziona per te o incontri qualche difficoltà, ti aiuteremo sicuramente!

Una delle belle caratteristiche della tecnologia 1C:Enterprise è che la soluzione applicativa è stata sviluppata utilizzando la tecnologia forme gestite, può essere eseguito sia in un thin client (eseguibile) sotto Windows, Linux, MacOS X, sia come client Web per 5 browser: Chrome, Internet Explorer, Firefox, Safari, Edge e tutto senza modificare il codice sorgente dell'applicazione. Inoltre, esternamente, l'applicazione nel thin client e nel browser funziona e sembra quasi identica.
Trova 10 differenze (sotto il taglio 2 immagini):

Finestra cliente sottile su Linux:

La stessa finestra nel client Web (nel browser Chrome):

Perché abbiamo creato un client web? Parlando in modo un po 'patetico, il tempo ci ha assegnato un compito del genere. Per molto tempo, il lavoro su Internet è diventato un prerequisito per le applicazioni aziendali. Innanzitutto, abbiamo aggiunto la possibilità di lavorare via Internet per il nostro thin client (alcuni dei nostri concorrenti, tra l'altro, si sono fermati qui; altri, al contrario, hanno abbandonato il thin client e si sono limitati all'implementazione del web client). Abbiamo deciso di dare ai nostri utenti l'opportunità di scegliere l'opzione client più adatta a loro.

L'aggiunta di funzionalità Web al thin client è stata una grande impresa con un cambiamento completo nell'architettura client/server. La creazione di un client Web è un progetto completamente nuovo che è iniziato da zero.

Formulazione del problema

Quindi, i requisiti per il progetto: il web client deve fare lo stesso del thin client, vale a dire:

1. Visualizza l'interfaccia utente
2. Eseguire il codice client scritto in linguaggio 1C

L'interfaccia utente in 1C è descritta in un editor visivo, ma in modo dichiarativo, senza una disposizione degli elementi pixel per pixel; vengono utilizzate circa tre dozzine di tipi di elementi dell'interfaccia: pulsanti, campi di input (testo, digitale, data / ora), elenchi, tabelle, grafici, ecc.

Il codice client in linguaggio 1C può contenere chiamate al server, lavorare con risorse locali (file, ecc.), Stampare e molto altro.

Sia il thin client (quando si lavora tramite il Web) che il client Web utilizzano lo stesso set di servizi Web per comunicare con il server delle applicazioni 1C. L'implementazione dei client, ovviamente, è diversa: il thin client è scritto in C ++, il client Web è scritto in JavaScript.

Un po' di storia

Il progetto web client è iniziato nel 2006 con un team (medio) di 5 persone. In alcune fasi del progetto, gli sviluppatori sono stati coinvolti per implementare funzionalità specifiche ( documento foglio di calcolo, diagrammi, ecc.); di norma, questi erano gli stessi sviluppatori che hanno realizzato questa funzionalità nel thin client. Quelli. gli sviluppatori hanno riscritto i componenti in JavaScript che avevano precedentemente creato in C++.

Fin dall'inizio abbiamo scartato l'idea di una eventuale conversione automatica (almeno parziale) del codice C++ del thin client in JavaScript del web client a causa delle forti differenze concettuali tra i due linguaggi; il client Web è stato scritto in JavaScript da zero.

Nelle prime iterazioni del progetto, il client Web ha convertito il codice client nel linguaggio 1C integrato direttamente in JavaScript. Il thin client agisce in modo diverso: il codice nel linguaggio 1C integrato viene compilato in bytecode e quindi questo bytecode viene interpretato sul client. Successivamente, il client web ha iniziato a fare lo stesso: in primo luogo, ha dato un aumento delle prestazioni e, in secondo luogo, ha permesso di unificare l'architettura dei client thin e web.

La prima versione della piattaforma 1C:Enterprise con supporto client Web è stata rilasciata nel 2009. Il client Web a quel tempo supportava 2 browser: Internet Explorer e Firefox. I piani originali erano di supportare Opera, ma a causa di problemi insormontabili con i gestori di chiusura dell'applicazione in Opera in quel momento (non era possibile tracciare con certezza al 100% che l'applicazione si stava chiudendo, e in quel momento eseguire la procedura di disconnessione da l'application server 1C) da questi piani doveva essere abbandonato.

Struttura del progetto

In totale, la piattaforma 1C:Enterprise ha 4 progetti scritti in JavaScript:

1. I WebTools sono librerie condivise utilizzate da altri progetti (includiamo anche la Google Closure Library qui).
2. Controllo FormattedDocument
3. Controllo dello scheduler (implementato in JavaScript sia nel thin client che nel client Web)
4. Cliente web

La struttura di ciascun progetto ricorda la struttura dei progetti Java (o progetti .NET, a seconda di quale sia più vicino a te); abbiamo spazi dei nomi e ogni spazio dei nomi si trova cartella separata. All'interno della cartella ci sono i file e le classi dello spazio dei nomi. Ci sono circa 1000 file nel progetto web client.

Strutturalmente, il client Web è in gran parte suddiviso nei seguenti sottosistemi:

• Interfaccia dell'applicazione client gestita
  • Interfaccia generale dell'applicazione (menu di sistema, pannelli)
  • Interfaccia dei moduli gestiti, che comprende, tra l'altro, circa 30 controlli (pulsanti, Vari tipi campi di input - testo, digitale, data/ora, ecc., tabelle, elenchi, grafici, ecc.)
• Modello a oggetti disponibile per gli sviluppatori sul client (più di 400 tipi in totale: modello a oggetti dell'interfaccia gestita, impostazioni di composizione dei dati, formattazione condizionale, ecc.)
• Interprete linguistico incorporato 1C
• Estensioni del browser (utilizzate per funzionalità non supportate in JavaScript)
  • Lavorare con la crittografia
  • Lavorare con i file
  • Tecnologia componenti esterni, consentendone l'utilizzo sia nei thin client che nei web client

Funzionalità di sviluppo

Implementare tutto quanto sopra in JavaScript non è un compito facile. Forse il client Web 1C è una delle più grandi applicazioni lato client scritte in JavaScript: circa 450.000 righe. Utilizziamo attivamente un approccio orientato agli oggetti nel codice del client web, che semplifica il lavoro con un progetto così grande.

Per ridurre al minimo le dimensioni del codice client, abbiamo prima utilizzato il nostro offuscatore e, a partire dalla versione 8.3.6 della piattaforma (ottobre 2014), abbiamo iniziato a utilizzare Google Closure Compiler . L'effetto dell'utilizzo in numeri è la dimensione del framework del client Web dopo l'offuscamento:

• Offuscatore proprio - 1556 kb
• Compilatore di chiusura di Google - 1073 kb

L'utilizzo di Google Closure Compiler ci ha aiutato a migliorare le prestazioni del client web del 30% rispetto al nostro offuscatore. Inoltre, la quantità di memoria consumata dall'applicazione è diminuita del 15-25% (a seconda del browser).

Google Closure Compiler funziona molto bene con il codice orientato agli oggetti, quindi la sua efficienza è la più alta per un client web. Il compilatore di chiusura fa alcune cose buone per noi:

• Controllo del tipo statico nella fase di compilazione del progetto (fornito dal fatto che copriamo il codice con annotazioni JSDoc). Il risultato è una tipizzazione statica, molto vicina al livello della digitazione in C++. Questo aiuta a rilevare una percentuale piuttosto elevata di errori nella fase di compilazione del progetto.
• Riduzione delle dimensioni del codice attraverso l'offuscamento
• Una serie di ottimizzazioni del codice eseguibile, ad esempio, come:
  • sostituzioni di funzioni inline. Chiamare una funzione in JavaScript è un'operazione piuttosto costosa e le sostituzioni in linea di piccoli metodi usati di frequente possono velocizzare notevolmente il codice.
  • Conteggio delle costanti in fase di compilazione. Se l'espressione dipende da una costante, verrà sostituita con il valore effettivo della costante

Utilizziamo WebStorm come ambiente di sviluppo del nostro client web.

Per l'analisi del codice utilizziamo SonarQube, dove integriamo analizzatori di codice statici. Con l'aiuto di analizzatori, monitoriamo il degrado della qualità del codice sorgente JavaScript e cerchiamo di prevenirlo.

Quali compiti abbiamo risolto/stiamo risolvendo

Durante l'implementazione del progetto, abbiamo dovuto affrontare una serie di compiti interessanti che dovevamo risolvere.

Scambio dati con il server e tra finestre

Ci sono situazioni in cui l'offuscamento del codice sorgente può interferire con il funzionamento del sistema. Il codice esterno al codice eseguibile del client Web, a causa dell'offuscamento, può avere nomi di funzioni e parametri diversi da quelli previsti dal nostro codice eseguibile. Il codice esterno per noi è:

• Codice proveniente dal server come strutture dati
• Codice per un'altra finestra dell'applicazione

Per evitare l'offuscamento durante l'interazione con il server, utilizziamo il tag @expose:

/** * @constructor * @extends(Base.SrvObject) */ Srv.Core.GenericException = function () ( /** * @type (string) * @expose */ this.descr; /** * @type (Srv.Core.GenericException) * @expose */ this.inner; /** * @type (stringa) * @expose */ this.clsid; /** * @type (boolean) * @expose */ this. codificato;)
E per evitare l'offuscamento durante l'interazione con altre finestre, utilizziamo le cosiddette interfacce esportate (interfacce in cui vengono esportati tutti i metodi).

/** * Interfaccia esportata del controllo DropDownWindow * * @interface * @struct */ WebUI.IDropDownWindowExp = function()() /** * Sposta la selezione avanti o indietro di 1 * * @param (boolean) isForward * @ param (boolean ) checkOnly * @return (boolean) * @expose */ WebUI.IDropDownWindowExp.prototype.moveMarker = function (isForward, checkOnly)() /** * Sposta la selezione all'inizio o alla fine * * @param (boolean ) isFirst * @param (booleano) checkOnly * @return (booleano) * @expose */ WebUI.IDropDownWindowExp.prototype.moveMarkerTo = function (isFirst, checkOnly)() /** * @return (booleano) * @expose */ WebUI.IDropDownWindowExp.prototype .selectValue = function()()

Abbiamo usato Virtual DOM prima che diventasse mainstream)

Come tutti gli sviluppatori che si occupano di interfacce utente Web complesse, ci siamo subito resi conto che il DOM non è adatto alle interfacce utente dinamiche. Quasi immediatamente, è stato implementato un analogo del Virtual DOM per ottimizzare il lavoro con l'interfaccia utente. Durante l'elaborazione degli eventi, tutte le modifiche del DOM vengono archiviate in memoria e, solo quando tutte le operazioni sono state completate, le modifiche accumulate vengono applicate all'albero del DOM.

Ottimizzazione del client web

Per rendere il nostro client web più veloce, cerchiamo di utilizzare al massimo le funzionalità standard del browser (CSS, ecc.). Quindi, la barra dei comandi del modulo (che si trova su quasi tutti i moduli di domanda) è disegnata esclusivamente dal browser, layout dinamico basato su CSS.

Test

Per i test funzionali e delle prestazioni, utilizziamo uno strumento proprietario (scritto in Java e C++) e una suite di test costruita su Selenium .

Il nostro strumento è universale: ti consente di testare quasi tutti i programmi per finestre e quindi è adatto per testare sia un thin client che un client Web. Lo strumento registra le azioni dell'utente che ha avviato la soluzione applicativa 1C in un file di script. Allo stesso tempo, vengono registrate le immagini dell'area di lavoro dello schermo - riferimenti. Durante il monitoraggio delle nuove versioni del client Web, gli scenari vengono riprodotti senza la partecipazione dell'utente. Nei casi in cui lo screenshot non corrisponde a quello di riferimento in nessuna fase, il test viene considerato fallito, dopodiché lo specialista della qualità conduce un'indagine: si tratta di un errore o di una modifica pianificata nel comportamento del sistema. In caso di comportamento pianificato, gli standard vengono automaticamente sostituiti da nuovi.

Lo strumento misura anche le prestazioni dell'applicazione con una precisione di 25 millisecondi. In alcuni casi, eseguiamo il loop di parti dello script (ad esempio, ripetendo più volte l'inserimento dell'ordine) per analizzare il degrado del tempo di esecuzione nel tempo. I risultati di tutte le misurazioni vengono registrati in un registro per l'analisi.

Il nostro strumento di test e l'applicazione in fase di test

Il nostro strumento e il selenio si completano a vicenda; ad esempio, se un pulsante su uno degli schermi ha cambiato posizione, Selenium potrebbe non rintracciarlo, ma il nostro strumento lo noterà, perché effettua un confronto pixel per pixel dello screenshot con lo standard. Inoltre, lo strumento è in grado di rintracciare i problemi con l'elaborazione dell'input dalla tastiera o dal mouse, poiché è quello che riproduce.

I test su entrambi gli strumenti (il nostro e Selenium) eseguono scenari di lavoro tipici delle nostre soluzioni applicative. I test vengono avviati automaticamente dopo la build giornaliera della piattaforma 1C:Enterprise. Se gli script rallentano (rispetto alla build precedente), indagheremo e risolveremo la causa del rallentamento. Il nostro criterio è semplice: il nuovo assemblaggio non dovrebbe funzionare più lentamente del precedente.

Gli sviluppatori utilizzano diversi strumenti per indagare sugli incidenti di rallentamento; utilizzato principalmente è Dynatrace AJAX Edition di DynaTrace. Vengono registrati i registri dell'esecuzione dell'operazione problematica sul precedente e sul nuovo assemblaggio, quindi vengono analizzati i registri. Allo stesso tempo, il tempo di esecuzione delle singole operazioni (in millisecondi) potrebbe non essere un fattore decisivo: i processi di servizio come la raccolta dei rifiuti vengono periodicamente avviati nel browser, possono sovrapporsi al tempo di esecuzione delle funzioni e distorcere l'immagine. Parametri più rilevanti in questo caso sarebbero il numero di istruzioni JavaScript eseguite, il numero di operazioni atomiche sul DOM e così via. Se il numero di istruzioni/operazioni nello stesso scenario in nuova versione aumentato - questo significa quasi sempre un calo delle prestazioni che deve essere corretto.

Inoltre, uno dei motivi del calo delle prestazioni potrebbe essere che il compilatore di chiusura di Google per qualche motivo non è riuscito a effettuare una sostituzione in linea della funzione (ad esempio, perché la funzione è ricorsiva o virtuale). In questo caso si cerca di rimediare alla situazione riscrivendo il codice sorgente.

Estensioni del browser

Nel caso in cui una soluzione applicata necessiti di funzionalità che non sono in JavaScript, utilizziamo le estensioni del browser:

• per lavorare con i file
• lavorare con la crittografia
• lavorando con componenti esterni

Le nostre estensioni sono composte da due parti. La prima parte è quella che viene chiamata un'estensione del browser (solitamente estensioni JavaScript per Chrome e Firefox) che interagiscono con la seconda parte, un'estensione binaria che implementa la funzionalità di cui abbiamo bisogno. Va detto che scriviamo 3 versioni di estensioni binarie - per Windows, Linux e MacOS. L'estensione binaria viene fornita come parte della piattaforma 1C:Enterprise e si trova sul server delle applicazioni 1C. La prima volta che viene richiamato dal client Web, viene scaricato sul computer client e installato nel browser.

Quando si lavora in Safari, le nostre estensioni utilizzano NPAPI, quando si lavora in Internet Explorer - tecnologia ActiveX. Microsoft Edge non supporta ancora le estensioni, quindi il client Web funziona con limitazioni.

Ulteriori sviluppi

Uno dei gruppi di attività per il team di sviluppo del client Web è ulteriori sviluppi funzionalità. La funzionalità del client Web dovrebbe essere identica alla funzionalità del thin client, tutte le nuove funzionalità vengono implementate contemporaneamente sia nel thin client che nel client Web.

Altre attività sono lo sviluppo dell'architettura, il refactoring, il miglioramento delle prestazioni e dell'affidabilità. Ad esempio, una delle direzioni è l'ulteriore movimento verso un modello di lavoro asincrono. Parte della funzionalità del web client è attualmente costruita su un modello sincrono di interazione con il server. Il modello asincrono sta diventando sempre più rilevante nei browser (e non solo nei browser), e questo ci costringe a modificare il web client sostituendo le chiamate sincrone con quelle asincrone (e refactoring del codice di conseguenza). Il passaggio graduale a un modello asincrono è spiegato dalla necessità di supportare le soluzioni rilasciate e adattarle gradualmente.

Tag: aggiungi tag

Esiste un server Windows con 1C 8.3 (DB - MSSQL).
L'attività consiste nell'impostare la pubblicazione del database su un server Web Linux.
Sottigliezze: il modulo 1C per Apache funziona solo con 2.0 e 2.2 e Versione attuale nella maggior parte delle distribuzioni - 2.4+
Scrivo di più per me stesso, per non dimenticare. Beh, non si sa mai, all'improvviso qualcun altro tornerà utile: non devi correre nei forum alla ricerca dei comandi giusti.

Iron: ha fornito un gigabyte di RAM, un core e 20 gigabyte di disco. Non è mai troppo tardi per espandersi.
Sistema operativo: Debian Stable, ci sono abituato.

Ho impostato il minimo, incluso il server ssh, ma escluso il web. Torniamo a questo.

Dopo l'installazione configurazione di base a piacere, di solito imposto il locale su utf8, metto sudo, mc e vim, il resto secondo necessità.
Successivamente, è necessario installare Apache 2.2. E fallo il modo giusto piuttosto che scaricare semplicemente il pacchetto deb. :)

Innanzitutto, aggiungi righe a /etc/apt/sources.list con un collegamento a versione precedente distribuzione.
deb http://mirror.yandex.ru/debian/ wheezy principale deb-src http://mirror.yandex.ru/debian/ wheezy principale
Puoi, ovviamente, scrivere oldstable- anche al momento sarà corretto. Ma solo in quella vera, perché prima o poi uscirà una nuova versione stabile e dentro oldstable e poi invece di apache 2.2 ci sarà 2.4. Anche se, spero, a quel punto 1C verrà aggiornato e funzionerà con le versioni più recenti di Apache. Ma chi lo sa? :)
Dove mirror.yandex.ru- il nome del tuo server preferito con il repository è scritto lì.

Quindi aggiorniamo gli indici - aggiornamento apt-get- e guarda cosa abbiamo qui per apache con il comando apt-cache showpkg apache2
C'è molto output, ma siamo interessati solo all'inizio dell'output:
Pacchetto: apache2 Versioni: 2.4.10-10+deb8u3 (/var/lib/apt/lists/mirror.yandex.ru_debian_dists_stable_main_binary-i386_Packages) i386_Packages MD5: Descrizione Lingua: en File: /var/lib/apt/lists/mirror. yandex.ru_debian_dists_stable_main_i18n_Translation-en MD5: Linguaggio di descrizione: en File: /var/lib/apt/lists/mirror.yandex.ru_debian_dists_stable_main_i18n_Translation-en MD5 : 2.4.10-10+deb8u1 (/var/lib/apt/lists/security. debian.org_dists_stable_updates_main_binary-i386_Packages) Lingua: en File: /var/lib/apt/lists/mirror.yandex.ru_debian_dists_stable_main_i18n_Translation-en MD5: Description Language: en File: /var/lib/apt/lists/mirror.yandex.ru_debian_dists_stable_main_i18n_Translation- it MD5: 2.2.22 -13+deb7u6 (/var/lib/apt/lists/mirror.yandex.ru_deb ian_dists_wheezy_main_binary-i386_Packages) Lingua di descrizione: File: /var/lib/apt/lists/mirror.yandex.ru_debian_dists_wheezy_main_binary-i386_Packages MD5: Lingua di descrizione: en File: /var/lib/apt/lists/mirror.yandex.ru_debian_dists_wheezy_main_i18n_Translation : Lingua di descrizione : ru File: /var/lib/apt/lists/mirror.yandex.ru_debian_dists_wheezy_main_i18n_Translation-ru MD5:

Vediamo che oltre alla 2.4.10 c'è la versione 2.2.22-13+deb7u6 - ciò di cui hai bisogno.
Abbiamo messo: apt-get install apache2=2.2.22-13+deb7u6
O più precisamente: 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 e il resto delle dipendenze verrà automaticamente richiamato.

Successivamente, mettiamo Apache in attesa per non aggiornarlo per sbaglio.

Apt-mark hold apache2 apache2-mpm-worker apache2.2-common apache2.2-bin apache2 è contrassegnato come commit. apache2-mpm-worker è contrassegnato come commit. apache2.2-common è contrassegnato come commit. apache2.2-bin è contrassegnato come commit.
Puoi eseguire il servizio apache2 start e telnet sulla porta 80 per verificare se sei troppo pigro per avviare il browser.

host locale telnet 80
Sto provando::1... Connesso a localhost. Il carattere di escape è "^]". 1

Metodo non implementato

1 a /index.html non supportato.

---

Server Apache/2.2.22 (Debian) su 1cweb Porta 80

Connessione chiusa da un host straniero.

Giura: significa che funziona.

Ora mettiamo 1C.
Sono necessari solo i servizi Web 1C (package 1c-impresa83-ws). E 1c-impresa83-comune, che è registrato nelle dipendenze. E 1c-enterprise83-server, che non è specificato nelle dipendenze, ma senza di esso, l'utilità di pubblicazione scrive "Errore di segmentazione".
In linea di principio, è necessario solo il modulo per Apache wsap22.so dal pacchetto 1c-impresa83-ws, e tutto il resto può passare editor di testo Fare. Ma sono una persona pigra e preferirei spendere qualche megabyte su 1C piuttosto che guidare manualmente le linee nelle configurazioni. :)

Successivamente, è necessario creare una cartella per memorizzare le impostazioni del database pubblicato 1C. È possibile nell'albero del server Web, ma è meglio che lo faccia separatamente, proprio alla radice, /1s.
Successivamente, dalla cartella con file installati 1C ( /opt/1C/v8.3/i386) eseguire l'utilità di pubblicazione webinst con i seguenti parametri (pubblico il nostro database di test):
./webinst -apache22 -wsdir testlitupp -dir /1c/testlitupp -connstr "Srvr=10.0.0.4;Ref=testlitupp;" -confPath /etc/apache2/apache2.conf Pubblicato

Apache22 - la nostra versione del server web
-wsdir testlitupp - cartella sul server web dove sarà disponibile il database pubblicato (http://yourserver/testlitupp)
-dir /1c/testlitupp - cartella in cui verrà archiviato il file default.vrd con le impostazioni di pubblicazione
-connstr "Srvr=10.0.0.4;Ref=testlitupp;" - IP del server 1C e nome del database pubblicato
-confPath /etc/apache2/apache2.conf - percorso della configurazione di apache

Se dice "Pubblicato", allora è andato tutto bene. Se dice "Errore di segmentazione", molto probabilmente ti sei dimenticato di inserire 1c-enterprise83-server.
Sulla base dei risultati, abbiamo il file default.vrd

E alcune nuove righe nel file di configurazione del server web:

LoadModule _1cws_module "/opt/1C/v8.3/i386/wsap22.so" # 1c pubblicazione Alias ​​"/testlitupp" "/1c/testlitupp/" AllowOverride Tutte le opzioni Nessuno Ordine consenti, nega Consenti da tutte le applicazioni SetHandler 1c ManagedApplicationDescriptor "/1c/testlitupp/default.vrd"
Riavviamo Apache (servizio apache2 restart) e andiamo a vedere cosa è stato pubblicato lì.
Pubblicato, richiede una password.

E lascialo entrare nella base.

Lavori. Ulteriori impostazioni di pubblicazione vengono effettuate modificando i file vrd (ad esempio, abilitando il debug) e i tuoi programmatori 1C dovrebbero essere coinvolti nel completamento dell'interfaccia del client web.
Se aggiungi opzioni, ad esempio, con la connessione manuale dei servizi, non dimenticare di rimuovere l'ultima barra nella riga "base="/testlitupp" ib="Srvr=10.0.0.4;Ref=testlitupp;" nell'impostazione predefinita. file vrd / >", ci ho giocherellato a lungo. Se non si elimina e si aggiunge qualcosa dopo, viene visualizzato un "errore 500" senza ulteriori informazioni.
Quale sarà il carico sul server Web: non lo so ancora, per noi funziona ancora in modalità test e ci sono risorse allocate sufficienti. Ma aggiungere memoria o core all'aumentare delle esigenze non è un problema.

In generale, in altro distribuzioni linux tutto è fatto allo stesso modo, le differenze sono solo nei metodi di installazione vecchia versione apache.