Parámetros configurables de Velneo vServer

Los parámetros que indicamos a continuación se configuran en el registro del sistema.

En Windows, se configuran en la rama de registro del servidor:

  • En el usuario system:

  • HKEY_USERS.DEFAULT\Software\Velneo\vServer

  • En el usuario en curso (cuando el servicio VATP está asociado a la cuenta de un usuario y queremos configurar los parámetros para ese usuario, debemos hacerlo en una sesión de Windows de dicho usuario):

    • HKEY_CURRENT_USER\Software\Velneo\vServer

En Linux, se ha de configurar en el usuario con el que se vaya a iniciar el servicio:

  • ~/.config/Velneo/vServer.conf

En Velneo cloud:

Se configura en el fichero /.config/Velneo/vServer.conf. Para poder editarlo debemos usar el explorador de archivos cloud sftp.

La clave se lee en el arranque del servidor y al parar el servidor se guarda la configuración. Por tanto, para cambiar la configuración requiere tener parado el servidor.

Configurar días de caducidad de contraseña

La entrada se llama PasswordsDays.

Si un usuario se ha configurado para que su contraseña caduque, se entenderá que ésta caducará transcurrido un tiempo. Por defecto son 90 días, pero este tiempo es configurable.

El valor por defecto es 90 (=90 días).

Configurar tiempo de desbloqueo de cuenta

La entrada se llama PasswordsMinWait.

Cuando un usuario intenta conectarse a un Velneo vServer y hace nueve intentos fallidos, el sistema bloquea automáticamente la cuenta. Este parámetro permite configurar el número de minutos que deben trascurrir para que la cuenta sea desbloqueada nuevamente.

Este tiempo de desbloqueo de cuenta, por defecto es de 1 minuto y, si mientras está bloqueada la cuenta el usuario vuelve a introducir unas credenciales erróneas, se incrementará otro minuto más por cada fallo.

El valor por defecto es 1, que equivale a 1 minuto.

Una vez iniciado Velneo vServer podemos comprobar en los mensajes del log de sistema qué valor está tomando.

Configurar timeout para expulsión de enganches inactivos

La entrada se llama ConnectionExpiredSeconds.

Si un enganche de un cliente de ejecución (Velneo vClient, por ejemplo), se ha perdido, en enganche quedará activo en el servidor durante 300 segundos, pero este tiempo es configurable para servidores licenciados (es decir, no es configurable para servidores sin licenciar).

Mediante este parámetro podremos configurar La entrada se llama ConnectionExpiredSeconds y el valor por defecto es 300 segundos. El tiempo debemos indicarlo en segundos. La clave se lee en el arranque del servidor y al parar el servidor se guarda la configuración en el usuario que ejecuta el servidor, de dónde la recogerá de entonces en adelante. Por tanto, para cambiar la configuración requiere tener parado el servidor.

Esta clave no se crea por defecto, debemos crearla nosotros manualmente, al tratarse de un dato numérico, el tipo es DWORD32.

El servidor cuando arranque de nuevo, buscará primero en su usuario, si ahí no tiene valor, entonces buscará en la rama de la máquina. Una vez que lo obtenga de la máquina, se lo guarda en la rama del usuario correspondiente, y lo leerá a partir de entonces ahí.

De esta forma, podemos establecer un valor por defecto inicial, pero siempre tendremos la posibilidad de modificar el dato para un servidor en concreto, si hay más de uno en la máquina.

Una vez iniciado Velneo vServer podemos comprobar en los mensajes del log de sistema qué valor está tomando.

Configurar del nivel de detalle en los mensajes de Velneo vServer (verbose)

Permite configurar el nivel de verbose para registrar eventos realizados por Velneo vServer. Estos eventos serán mostrados en el panel de salida de mensajes de Velneo vAdmin.

La entrada se llama VerboseLevel y contiene un valor entero.

Los valores posibles van de 0 a 8, siendo 0 el valor más bajo detalle y 8 es el valor más alto de detalle.

  • Nivel bajo: 0, 1, 2

  • Nivel medio: 3, 4, 5

  • Nivel alto: 6, 7, 8

En el apartado de Monitorización de Velneo vAdmin puedes conocer los logs que se pueden activar mediante el valor de VerboseLevel.

Haz clic aquí para conocer con más detalle los tipos de mensaje que se pueden generar.

Una vez iniciado Velneo vServer podemos comprobar en los mensajes del log de sistema qué valor está tomando.

Activar log de procesos

Es posible activar un log para, en un momento dado, poder hacer un seguimiento de los siguientes objetos/subobjetos ejecutados en el servidor:

Se activa configurando el valor 9 en la entrada VerboseLevel. Si lo activamos, en el panel de salida de mensajes de Velneo vAdmin se mostrarán los mensajes de nivel alto y, además, se generará dentro de la carpeta server del directorio de configuración del servidor un fichero de texto plano que sigue el estándar log4j.

Se genera un fichero por día con el formato prcAAMMDD.log. Ejemplo: prc230919.log y su contenido tiene la siguiente estructura:

El contenido de este fichero no se mostrará en Velneo vAdmin. así que podremos, o bien editar el fichero en un editor de textos, o bien, utilizar herramientas externas compatibles con el estándar log4j para analizarlo.

De cada proceso, trigger o función remota ejecutados se generarán dos líneas: una al iniciar su ejecución y otra al finalizarla que indicará además si ha terminado correctamente o no.

En cada línea se mostrará:

  • Fecha y hora.

  • Clasificación: procesos, funciones o triggers.

  • Momento (Inicio o Finalizado).

  • Identificador y nombre del proceso, trigger o función ejecutado.

  • Tipo de objeto: proceso, función o trigger.

  • Testigo del enganche.

  • Usuario que lo ha ejecutado.

  • Código, identificador y nombre de la instancia del proceso, trigger o función ejecutado.

  • Código, identificador y nombre del proyecto donde se ha ejecutado.

Ejemplo:

0	2023-09-19T10:18:36	Procesos	Inicio de proceso	ObjetoId:	ALTA_FACTURA	ObjetoNombre:	Alta factura	ObjetoTipo:	Proceso	Testigo:	2-59-156-3518	Usuario:	velneo	InstanciaCodigo:	214	InstanciaId:	PRUEBA_LOGS_APP_PRUEBA_LOGS_DAT	InstanciaNombre:	prueba_logs_app_prueba_logs_dat	ProyectoId:	98moagk0.vcd	ProyectoAlias:	prueba_logs_dat	ProyectoNombre:	prueba_logs_dat
0	2023-09-19T10:18:36	Procesos	Proceso finalizado con resultado: error	ObjetoId:	ALTA_FACTURA	ObjetoNombre:	Alta factura	ObjetoTipo:	Proceso	Testigo:	2-59-156-3518	Usuario:	velneo	InstanciaCodigo:	214	InstanciaId:	PRUEBA_LOGS_APP_PRUEBA_LOGS_DAT	InstanciaNombre:	prueba_logs_app_prueba_logs_dat	ProyectoId:	98moagk0.vcd	ProyectoAlias:	prueba_logs_dat	ProyectoNombre:	prueba_logs_dat

Configurar el número de colas para procesos en 4º plano

Si un Velneo vServer tiene activada la funcionalidad que permite gestionar múltiples colas, podremos configurar el número de colas que estarán disponibles para la ejecución de procesos en 4º plano.

La entrada se llama nqueues y su valor será un número entero con el nº de colas a iniciar.

Por defecto, Velneo vServer configura 9 colas para la ejecución de procesos en 4º plano. Con esta entrada podemos configurar un número máximo de colas disponibles distinto.

También podemos configurarlas en el arranque del vServer. Así que la prioridad será:

  1. Parámetro establecido en el arranque.

  2. Si no se establece en el arranque comprobará si existe esta entrada.

  3. Si no se indica en el arranque ni hemos configurado entrada alguna, arrancará con la configuración por defecto.

Cuando en un proyecto declaramos varios objetos de tipo cola, podremos configurar en el servidor, por instancia, qué número de cola física usará cada una de las colas declaradas en el proyecto.

Es decir, sin en una solución hemos definido tres objetos cola y la tenemos instanciada en un servidor, podremos configurar qué número de cola física usará cada una de las colas declaradas en la solución.

Esto nos permitirá que distintas instancias usen distintos números de cola.

El uso de varias colas permite que los procesos asíncronos se procesen antes, ya que cada cola se procesa de manera independiente.

Para configurar qué colas físicas usarán las colas declaradas en cada proyecto debemos crear dentro de la carpeta server del directorio de configuración del servidor un fichero de texto con codificación UTF8 denominado colas.conf con la siguiente estructura JSON:

[
  {
    "instanciaId" : "IDINSTANCIA1",
    "colas" : [
      {
        "colaId" : "IDCOLA1",
        "colaNumero" : 1
      },
      {
        "colaId" : "IDCOLA2",
        "colaNumero" : 8
      }
    ] 
  },
  {
    "instanciaId" : "IDINSTANCIA4",
    "colas" : [
      {
        "colaId" : "IDCOLA7",
        "colaNumero" : 1
      },
      {
        "colaId" : "IDCOLA2",
        "colaNumero" : 3
      }
    ] 
  }
]

Contendrá un array de instancias y, por cada instancia, un array de colas.

En el objeto instanciaId se indicará, entre comillas, el identificador de la instancia (que veremos en vAdmin):

En el objeto colaId, indicaremos el identificador que tiene un objeto cola en el proyecto instanciado.

En el objeto colaNumero, indicaremos el número de la cola física del servidor que usará ese objeto cola.

Ejemplo de JSON con dos instancias configuradas:

[
  {
    "instanciaId" : "vERP_CLIENTE1_APP",
    "colas" : [
      {
        "colaId" : "COLA1",
        "colaNumero" : 1
      },
      {
        "colaId" : "COLA2",
        "colaNumero" : 2
      },
	  {
        "colaId" : "COLA3",
        "colaNumero" : 3
      }
    ] 
  },
    {
    "instanciaId" : "vERP_CLIENTE2_APP",
    "colas" : [
      {
        "colaId" : "COLA1",
        "colaNumero" : 4
      },
      {
        "colaId" : "COLA2",
        "colaNumero" : 5
      },
	  {
        "colaId" : "COLA3",
        "colaNumero" : 6
      }
    ] 
  }
]

Si al disparar un proceso en 4º plano no se ha indicado ninguna cola, éste será enviado siempre a la cola 1.

Si al disparar un proceso en 4º plano la cola configurada en el proceso no existe, éste será enviado a la cola 1.

Si al disparar un proceso en 4º plano en una cola hay algún error en su configuración (el número de cola excede el rango de colas configuradas, por ejemplo) será enviado a la cola 1.

El fichero se lee en el arranque del servidor por lo que, si lo creamos o lo modificamos estando el servidor arrancado, debemos reiniciarlo para que tome la nueva configuración.

Configurar el timeout para mantener el hilo de las colas una vez vaciadas

Cuando se terminan de ejecutar todos los procesos de una cola, por defecto, el sistema mantiene el hilo de ésta abierto durante 1 segundo. Pero este timeout podemos configurarlo creando una entrada en el registro del sistema operativo. La clave se llama queueSecondsWaitDelay y su valor será un número entero con el nº de segundos a mantener el hilo abierto.

En servidores de producción es recomendable configurar esta clave con un valor de al menos 5 minutos (300 segundos) para optimizar el uso de recursos.

Configurar timeout para la expulsión del agente que ejecuta procesos en 5º plano

La entrada se llama AgentIdleSecondsToClose y su valor será un número entero correspondiente a un tiempo en segundos.

Nos permite configurar el tiempo que tiene que pasar para que, una vez finalizado un proceso que ha sido ejecutado en 5º plano, se cierre el agente que se ha abierto para ejecutarlo.

Si no se configura la clave, el agente será expulsado a los 9 segundos.

No podemos establecer un valor inferior a 9 segundos. Si establecermos un valor inferior, el sistema expulsará el agente pasados 9 segundos.

Configurar una expresión regular para la validación de contraseñas

Con el fin de asegurarnos la seguridad de las contraseñas, podremos configurar una expresión regular para validarlas, de modo que el sistema no deje establecer una contraseña que no la cumpla.

La entrada se llama PasswordsRegexValidation y su valor será la expresión regular que se quiera usar para validar las contraseñas. Ejemplo:

^(?=.*[a-z])(?=.*[A-Z])(?=.*\d)[a-zA-Z\d]{6,12}$

La expresión regular anterior exige que la contraseña tenga letras y números, alguna mayúscula y una longitud de entre 6 y 12 dígitos.

Una vez configurada y reiniciado el servidor, el sistema validará la contraseña cuando se intente cambar:

  • Estableciéndola directamente en el usuario en vAdmin.

  • Al conectarse desde cualquier componente cliente o bien cuando la contraseña ha caducado o bien cuando se ha configurado en el usuario que debe cambiarla.

  • Cuando se haga uso del comando de instrucción de proceso cambio de contraseña.

Este parámetro, en el caso de Linux como se usa el estándar de ficheros ini, debemos "escapar" tildes, ñ y otros caracteres como "\" si se usa en expresiones regulares. Ejemplo:

PasswordsRegexValidation="^(?=.*[a-z])(?=.*[A-Z])(?=.*\\d)[a-zA-Z\\d]{6,12}$"

Configurar control de repetición de contraseñas

Si queremos que Velneo vServer haga un control de contraseñas repetidas tendremos que crear una entrada llamada PasswordsRetention y su valor será el nº de contraseñas a guardar por usuario. De este modo, cuando se cambie la contraseña de un usuario, el sistema revisará su histórico de contraseñas y no dejará repetirla si coincide con alguna de las guardadas, emitiendo un mensaje de error.

Si no creamos esta entrada no se hará control de repetición de contraseñas.

Configurar mensaje de error cuando se intenta establecer una contraseña incorrecta

Cuando un usuario intenta introducir una contraseña incorrecta (está repetida, el dato que se pide repetir para establecer una nueva contraseña no es igual al otro, etc.) el sistema muestra un mensaje de error, pero nosotros podemos configurar uno que se añadirá a este, para completar la información.

Por ejemplo, si hemos establecido una expresión regular para validar la contraseña, podremos crear esta clave para añadir en el mensaje de error los requisitos que debe cumplir.

La entrada se llama PasswordsErrorMessage y su valor será el mensaje a mostrar cuando se produzca un error al intentar cambiar la contraseña. Siguiendo con el ejemplo de la expresión regular, el mensaje podría ser: La contraseña debe tener números, letras mayúsculas y minúsculas y una longitud de entre 6 y 12 caracteres.

Este parámetro, en el caso de Linux como se usa el estándar de ficheros ini, debemos "escapar" tildes, ñ y otros caracteres como "\" si se usa en el mensaje de error. Ejemplo:

PasswordsErrorMessage="\n\nNo has de repetir una contrase\xf1\x61 usada anteriormente y ha de contener n\xfameros, letras min\xfasculas y may\xfasculas, y un tama\xf1o entre 8 y 12 caracteres."

Incluir un certificado TLS/SSL propio

Esta funcionalidad permite indicar a Velneo vServer que haga uso de un certificado propio cuando se ejecute en modo SSL.

En primer lugar debemos disponer de un subdominio propio (ejemplo: clientes.midominio.com) y adquirir un certificado SSL para dicho subdominio. Podemos adquirirlo en una entidad certificadora, p.e. Gandi o en el servicio gratuito Letsencrypt.

El tipo de certificado soportado para VATPS es x509 y precisa un algoritmo tipo RSA.

No se pueden usar certificados con passphrase así que durante su creación, debemos desactivar/dejar en blanco ese valor. En el caso de que lo hayamos creado con passphrase tendremos que quitárselo.

Con OpenSSL podemos comprobar si el certificado se ha generado con passphrase del modo siguiente:

openssl rsa -modulus -noout -in micertificado.key | openssl md5

Donde sustituiremos "micertificado.key" por el nombre y extensión de nuestro fichero de clave del certificado.

Podemos quitar el passphrase con OpenSSL del modo siguiente:

openssl dsa -in micertificado.key -out micertificado.key_plain.key

Este comando toma el archivo original (en este ejemplo "micertificado.key" y crea una copia del mismo con el nombre que indicamos en el segundo parámetro (en nuestro ejemplo "micertificado.key_plain.key") sin lapassphrase.

El comando solicitará la passphrase para generarlo.

Ese nuevo fichero que se ha generado ("micertificado.key_plain.key" en nuestro ejemplo) es el que se ha de cargar en el servidor y no el original.

Una vez que dispongamos de nuestro certificado, debemos indicar al sistema la senda de los ficheros correspondientes a la parte pública y la parte privada del mismo.

En Windows: añadir dos valores de cadena:

  • CertificateKey y cuyo valor será la senda completa del fichero crt del certificado fullchain. Ejemplo: C:\crt\micertificado.crt

  • PrivateKey y cuyo valor será la senda completa del fichero key del certificado. Ejemplo: C:\crt\micertificado.key

Certificado fullchain: La cadena de confianza de una cadena de certificados es una lista ordenada de certificados, que contiene un certificado de suscriptor de usuario final y certificados intermedios, que representa la autoridad certificadora (CA) intermedia, que permite al receptor verificar que el emisor y todos los certificados intermedios son de confianza. Más información sobre esto en Wikipedia. Si necesitas información sobre cómo componerlo, haz clic aquí.

En Linux: añadir los valores en el fichero de configuración vServer.conf de esta manera:

CertificateKey=senda completa arhcivo fullchain  
PrivateKey=senda completa archivo key

Ejemplo:

CertificateKey=/crt/micertificado.crt  
PrivateKey=/crt/micertificado.key

El último paso será, en nuestro ISP, redirigir el subdominio para el que ha sido emitido el certificado (ejemplo: clientes.midominio.com) a la IP pública de la máquina donde esté instalado Velneo vServer.

A partir de ese momento, los usuarios deberán conectarse al servidor usando el subdominio (ejemplo: vatps://clientes.midominio.com), ya que si intentan conectarse usando la IP pública, los clientes obtendrán un error de SSL, ya que el certificado es válido solamente para el subdominio para el que se ha emitido.

En lo que respecta a Velneo Cloud la configuración de certificados es automática y transparente para el usuario.

Si necesitas configurar tu propio dominio de empresa tienes aquí toda la información.

El formato de ambos ficheros debe ser base64.

Podemos comprobar si el fichero del certificado es base64 editándolo en un editor de texto plano (Notepad, Notepad++) y comprobar que tiene el formato siguiente: empieza un con un encabezado -----BEGIN CERTIFICATE-----, terminar con un pie -----END CERTIFICATE----- y entre ambos el texto en base64 del certificado. Ejemplo:

-----BEGIN CERTIFICATE-----
TG9yZW0gaXBzdW0gZG9sb3Igc2l0IGFtZXQsIGNvbnNlY3RldHV
yIGFkaXBpc2NpbmcgZWxpdC4gSW50ZWdlciB2aXRhZSBibGFu
ZGl0IGxlby4gUGVsbGVudGVzcXVlIHNlZCBzZW0gaW1wZXJka
WV0LCBwb3N1ZXJlIG51bmMgdml0YWUsIHZ1bHB1dGF0ZSBy
aXN1cy4gTmFtIGJsYW5kaXQgdXQgbGVjdHVzIG5lYyB0ZW1wb
3IuIFBlbGxlbnRlc3F1ZSBpYWN1bGlzIGZlbGlzIG5lYyBleCBjb25k
aW1lbnR1bSwgdml0YWUgY29tbW9kbyBsZW8gbWFsZXN1YWR
hLiBEb25lYyBzaXQgYW1ldCBuaWJoIGluIGVuaW0gY29uZGltZW
50dW0gZmF1Y2lidXMuIEluIGRhcGlidXMgc29kYWxlcyBkb2xvciB
hdCBwb3J0dGl0b3IuIEFsaXF1YW0gdXQgYmliZW5kdW0gbGlnd
WxhLg==
-----END CERTIFICATE-----

También podemos comprobar si es correcto con OpenSSL, con el comando:

openssl x509 -in certificate.crt -text -noout

Donde "certificate.crt" lo reemplazaremos con el nombre y la extensión del fichero del certificado.

Podemos comprobar si el fichero de la clave privada del certificado es base64 editándolo en un editor de texto plano (Notepad, Notepad++) y comprobar que tiene el formato siguiente: empieza un con un encabezado -----BEGIN PRIVATE KEY-----, terminar con un pie -----END PRIVATE KEY----- y entre ambos el texto en base64 del certificado. Ejemplo:

-----BEGIN PRIVATE KEY-----
TG9yZW0gaXBzdW0gZG9sb3Igc2l0IGFtZXQsIGNvbnNlY3RldHV
yIGFkaXBpc2NpbmcgZWxpdC4gSW50ZWdlciB2aXRhZSBibGFu
ZGl0IGxlby4gUGVsbGVudGVzcXVlIHNlZCBzZW0gaW1wZXJka
WV0LCBwb3N1ZXJlIG51bmMgdml0YWUsIHZ1bHB1dGF0ZSBy
aXN1cy4gTmFtIGJsYW5kaXQgdXQgbGVjdHVzIG5lYyB0ZW1wb
3IuIFBlbGxlbnRlc3F1ZSBpYWN1bGlzIGZlbGlzIG5lYyBleCBjb25k
aW1lbnR1bSwgdml0YWUgY29tbW9kbyBsZW8gbWFsZXN1YWR
hLiBEb25lYyBzaXQgYW1ldCBuaWJoIGluIGVuaW0gY29uZGltZW
50dW0gZmF1Y2lidXMuIEluIGRhcGlidXMgc29kYWxlcyBkb2xvciB
hdCBwb3J0dGl0b3IuIEFsaXF1YW0gdXQgYmliZW5kdW0gbGlnd
WxhLg==
-----END PRIVATE KEY-----

También podemos comprobar si es correcto con OpenSSL, con el comando:

openssl rsa -in privateKey.key -check

Donde "privateKey.key" lo reemplazaremos con el nombre y la extensión del fichero de la clave privada del certificado.

Las entradas PasswordsDays, PasswordsMinWait y ConnectionExpiredSeconds también podemos configruarlas de forma general a la máquina. En Windows se creará en la clave HKEY_LOCAL_MACHINE\SOFTWARE\Velneo\vServer y en Linux en el fichero /etc/xdg/Velneo/vServer.conf.

Esto nos permitirá crear una configuración general por defecto para todos los servicios que se creen en una misma máquina. De este modo, cuando creemos un nuevo servicio, copiará esas entradas con los valores configurados en esta clave en el la del usuario asociado al nuevo servicio. Si queremos modificar el valor de alguna de ellas para un servicio concreto, lo cambiaremos en el usuario correspondiente.

Para el uso de certificados en intranets, consulta este enlace.

Desactivar la regeneración de índices en paralelo (bigkey)

La entrada se llama ParallelRegenDisabled, es de tipo binario y para desactivarla debemos asignarle un 1 como valor.

Desactiva la regeneración en paralelo (BigKey) en servidores con licencia de subscripción.

Una vez iniciado Velneo vServer podemos comprobar en los mensajes del log de sistema qué valor está tomando.

Parámetros del servicio

Se trata de parámetros que se han de configurar a nivel de servicio VATP. Se configuran del modo siguiente:

En Windows: para configurar el arranque del servidor en modo seguro es necesario añadir el parámetro en el valor de la clave "ImagePath" de la entrada de registro:

HKEY_LOCAL_MACHINE/SYSTEM/ControlSet001/services/Vatp Service XX.X.XXXX.XXXXX

En Linux: simplemente se incluye este parámetro de arranque.

Estos parámetros son:

Activar log (/log)

Permite generar un log en el directorio del trabajo servidor.

En el log se irán guardando todas las operaciones del protocolo con fecha, hora y texto descriptivo.

Ejemplo de mensaje:

2021-10-21T16:58:13 [INFO] Buscar entre límites Grupo: Ejecución Conexión: 6 Parámetro1: 2-5-5-1358 Parámetro2: ARTICULOS Parámetro3: ID Resultado: Ok InstanciaCodigo: 120 InstanciaId: GESTIONPYME_APP_GESTIONPYME_DAT InstanciaNombre: gestionpyme_app_gestionpyme_dat ProyectoId: 6u65o9bq.vcd ProyectoAlias: gestionpyme_dat ProyectoNombre: gestionpyme_dat Usuario: velneo

Este parámetro solamente se recomienda usarlo en el caso de que en Velneo nos lo recomienden durante el seguimiento de un soporte.

Configurar puerto de escucha /port

Solamente será necesario configurarlo en el caso de que nuestro servidor vaya a usar un puerto distinto al 690.

Para configurar el puerto de escucha debemos añadir en el parámetro ImagePath del servicio correspondiente, a continuación de la senda del fichero ejecutable de Velneo vServer el parámetro port: /port=nnnn, donde nnnn es el número de puerto por el que queremos acceder al servidor.

Iniciar en modo seguro (/norun)

Esta funcionalidad está orientada a ayudarnos en el caso de que hayamos tenido problemas al arrancar un servidor debido a algún problema con instancias o con un proceso ON_INIT_SERVER.

En modo seguro, el servidor:

  • No arranca las instancias.

  • No permite ejecutar las aplicaciones.

  • No regenera tablas con cambios de estructura.

  • No deshace transacciones incompletas

Cuando el servidor arranca en modo seguro, nos permite:

  • Acceder con vAdmin para administrar el servidor.

  • Revisar y configurar las instancias.

  • Acceder con vDevelop para editar tus aplicaciones.

  • Hacer los cambios que necesites en tus aplicaciones.

Una vez resueltos los problemas de arranque, podemos volver a configurar nuestro servidor en modo normal.

Para volver a dejar el servicio en arranque normal, simplemente debemos pararlo y quitar el parámetro /norun

Esta funcionalidad también está disponible en el panel de control de los servidores del cloud de Velneo.

Activar IPV6 (/ipv6)

Esta funcionalidad está orientada a que Velneo pueda ser usado en redes IPV6.

Para configurarlo debemos añadir en el parámetro ImagePath del servicio correspondiente, a continuación de la senda del fichero ejecutable de Velneo vServer el parámetro /ipv6.

Establecer el número de colas para procesos en 4º plano (/queues=X)

Si un Velneo vServer tiene activada la funcionalidad que permite gestionar múltiples colas, este parámetro está orientado a configurar el número de colas que tendrá disponible el servidor para la ejecución de procesos en 4º plano.

Por defecto, Velneo vServer configura 9 colas para la ejecución de procesos en 4º plano. Con este parámetro podemos configurar un número distinto de colas.

También podemos configurarlas en el registro de sistema. Así que la prioridad será:

  1. Parámetro establecido en el arranque.

  2. Si no se establece en el arranque comprobará si existe esta entrada.

  3. Si no se indica en el arranque ni hemos configurado entrada alguna, arrancará con la configuración por defecto.

Las colas las podremos configurar únicamente en servidores locales propietarios. En Velneo Cloud se establecen automáticamente en función de tipo de servidor y el número de URCs.

Última actualización