meun5

Unfortunately no, end users are generally unable to influence the route their traffic takes to the destination. Routes are usually determined by what networks your ISP is peering with and what routes those peer networks announce. However some routes will change all the time as load changes along the different paths and routers redirect traffic to different peers. Things you can do that can influence the route are, 1) change the destination. If there are other servers that provide the service, perhaps the route to them will be less congested. 2) Change the source. This is harder to do you do not have multiple ISPs available. 3) Use a proxy or middleman service to proxy the traffic for you. Depending on what you are trying to do, a VPN may be of use.

What it appears that you want to do is setup virtual hosts. This would allow each site to have their own unique configuration, whilst still be hosted by the same NGINX instance. To do so, I am going to assume you already have NGINX installed. If not, here is a guide for RHEL: https://access.redhat.com/solutions/1211673. The latest NGINX version as of time of writing for RHEL 7 and 8 appears to be 1.14.1. Once NGINX is installed the configuration files will be in either /etc/nginx or /etc/opt/rh/rh-nginx114/nginx/, dependent on the package you install. Older versions may be in a different folder. You will have to consult the manual that came with your NGINX installation. The rest of this post will assume that the configuration directory is /etc/nginx Once you have determined the configuration file location, you can then configure NGINX to load different virtual hosts. Typically, the main configuration file is nginx.conf, however this may be different depending on system configuration. Look for the include directive approximately 3/4 of the way through the file. Usually, it will state something similar to this, include /etc/nginx/conf.d/*.conf; but that may be different dependent on the version of NGINX installed. Older versions may have this instead, include /etc/nginx/sites-enabled/*; That directive refers to path where NGINX will look for additional configuration files. You may add more include directives to nginx.conf if you wish to add additional configuration directories. The rest of this post will assume /etc/nginx/conf.d/ is the directory for additional configuration files. Note: whilst you may add virtualhost configurations directly to the main nginx.conf file, it is best practice to separate each site into its own file. The rest of this post will assume that each site will have its own virtualhost file. Once the additional configuration directory has been determined, we can now setup virtual hosts. Create a new file in the /etc/nginx/conf.d/. With the defaults with this directory, NGINX will only interpret files with the .conf extension, but is dependent on system and service configuration. Best practice is usually have the site address as the file name, for example: sub.domain.ru.conf, for the address: sub.domain.ru. This is up to personal preference though. Once this file has been created, a virtual host block can be added to it. Virtual host blocks typically have the following format: server { listen 443 ssl http2; # HTTP/2 TLS IPv4 Listen Directive listen [::]:443 ssl http2; # HTTP/2 TLS IPv6 Listen Directive server_name sub.domain.ru; # The Domain for this Virtual Host charset utf-8; # Charset to use. Usually UTF-8 is fine. Consult the documentation of the software to determine if a more appriopiate charset is needed. ssl_certificate /etc/pki/tls/sub.domain.ru/fullchain.pem; # Path to the TLS Certificate ssl_certificate_key /etc/pki/tls/sub.domain.ru/privkey.pem; # Path to the TLS Certificate Key ssl_protocols TLSv1.2 TLSv1.1; # TLS Protocols to use. ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256'; # TLS Ciphers to use ssl_prefer_server_ciphers on; # Prefer server ciphers to mitigate downgrade attacks. add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"; # Enable HSTS with preloading ssl_stapling on; # Enable OSCP Stapling. This reduces the traffic to OSCP responders. ssl_trusted_certificate /etc/pki/tls/sub.domain.ru/chain.pem; # List of Trusted Certificates used to verify client certificates if enabled and OCSP responses if ssl stapling is enabled. ssl_stapling_verify on; # Verify OSCP responses. root /srv/web; # The root of the application directory. # deny access to .htaccess files, if Apache's document root # concurs with nginx's one # location ~ /\.ht { deny all; } location / { ... } } The paths, and the root/location directives will be different depending on how you configure NGINX and what you want to do with NGINX. After you have created all your virtual hosts, it is best to run "nginx -t" as an appropriate user to ensure that there are no mistakes in the configuration. Once this has been done, you can reload NGINX to load the new configs. On RHEL, this is usually accomplished with "systemctl reload nginx", though the name of the service may change dependent on how NGINX was installed and configured. On other systems, it may be different. A reboot of the server would also work. Once all that is done, you can go ahead and test the virtual hosts and make sure they are all operating correctly. Note: The example configuration provided here is to be used as a starting point only, and has not been audited to ensure it meets current security and privacy guidelines or regulations. It is up to you to adjust it to meet all applicable laws and regulations. vhost.sample.conf

The issue appears to stem from the fact that Java 8u60 (according to https://www.oracle.com/technetwork/java/javase/8all-relnotes-2226344.html#R180_60) disables the RC4 tls cipher algorithm, which is used by iDRAC 6. In addition to adding the site to the Security Exclusion list as per above, we had to modify the java.security file and remove RC4 from the list of disabled algorithms. The security file can be found in $JAVA_HOME/lib/security (For Unix Based OSes) or %JAVA_HOME%\lib\security for Windows. The line is jdk.tls.disabledAlgorithms=... and we just copied the line then removed RC4. This should allow the Java App to connect to the Remote Console.

It appears that you are running a Windows Machine (as discerned from the package name), however that curses package does not support Windows. A similar package that does support Windows, is windows-curses, available as so on pip. At first glance, the functionality is the same, however I have not tested either of these packages. Source: https://www.devdungeon.com/content/curses-windows-python