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:
- /home/USUARIO/Velneo/.config/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.
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).
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.
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.
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
Una vez iniciado Velneo vServer podemos comprobar en los mensajes del log de sistema qué valor está tomando.
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.
- 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.
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.
La entrada se llama AgentIdleSecondsToClose y su valor será un número entero correspondiente a un tiempo en segundos.
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.
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.
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}$"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.
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."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.
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.
openssl rsa -modulus -noout -in micertificado.key | openssl md5Donde sustituiremos "micertificado.key" por el nombre y extensión de nuestro fichero de clave del certificado.
openssl dsa -in micertificado.key -out micertificado.key_plain.keyEste 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.
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-----
openssl x509 -in certificate.crt -text -nooutDonde "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-----
openssl rsa -in privateKey.key -checkDonde "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.
La entrada se llama ParallelRegenDisabled, es de tipo binario y para desactivarla debemos asignarle un 1 como valor.
Una vez iniciado Velneo vServer podemos comprobar en los mensajes del log de sistema qué valor está tomando.
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:
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.
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.
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.
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.
- 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 1d ago