Jump to content

streamlan

Members
  • Posts

    11
  • Joined

  • Last visited

Everything posted by streamlan

  1. I updated ESET Protect to 9.1.2301.0, and then I was able to see the Outdated components function in ESET. Also since the ODBC drivers were manually installed and mysql was configured through mysql-apt-config apt upgrade didn't blast them. Thanks
  2. Hello ESET, I was wondering what the proper way to keep the HOST OS updated on Debian whilst running ESET Protect on Linux? I'm afraid that if I do an apt update / apt full-upgrade it will update MySQL/ODBC, Tomcat9, OpenJDK11, and some specific dependency or version required for ESET Protect will be horked, and it'll break. The ESET Appliance which runs on CentOS7 has an update OS feature, but I've noticed on the Debian installs it never reminds the user about OS updates. Are there any tech articles with guidance on updating your Linux ESET Protect server? Or should I just apt-mark hold specific ESET dependencies on Linux and go from there? Thanks!
  3. Same GraphQL errors on a VM with 2 processors and 4GB of RAM. I believe this is some sort of Tomcat9/JVM issue in Debian, because it's now happening on a system which meets all the requirements for ESET's Recommended server size for a 10,000 machine deployment. I'm going to open a trouble ticket with ESET, as I'm under the gun in getting a customer using this new server.
  4. Hello ESET Forums, I'm pretty sure now after several installs that what I'm experiencing is a memory exhaustion issue with tomcat9/java. Specifically with Java's GraphQL library which is what builds I'm guessing these large multi paged queries to the webconsole. My virtual machines have 2CPUs and 2GB of ram with swap. What I'm seeing is that the second I add TLS/SSL into the mix, the GraphQL/Java process grows beyond what the process likes in terms of speed and then none of the queries work any longer. Without TLS the GraphQL/Java process has JUST enough working set memory without having to bother with TLS so it all works. I don't plan on ever managing more than 250 computers with this ERAServer, would ESET have any tips on optimizing Tomcat9 for tiny installations with LESS than 1000 computers? I saw the tech article about sizing recommendations and tried the tomcat9 option detailed here: b.Decrease memory usage (low performance systems): JAVA_OPTS="-Xms256m -Xmx2048m" Unfortunately it still bombs. Any help would be appreciated!
  5. Hey ESET and Forum folks. I'm going through the install again with a fine toothed comb, and VERY CAREFULLY reading the documentation. I believe I have somehow MISSED a TINY little step somewhere which is clobbering this install. I'm back at a fully functional ESET Protect Server with WebConsole install and everything is working. I also believe that I somehow clobbered something ESET needs, when I dove deep into tomcat9's SSL/TLS howto. I'm going to use a server.xml <Connection entry patterned after the KB6721 settings, and I'm going to put the PKCS12 keystore under /etc/tomcat9/.keystore and see if I can make this happen. I'll report back with my findings and specifically where I think I went wrong on the last go-around.
  6. YES! That's right. I bumped into the same issue. On the MySQL Server setup of the guide here: https://help.eset.com/protect_install/80/en-US/installation_linux.html?mysql_configuration.html Specifically: On the initial MySQL install on Debian, and in your instance on Ubuntu, if you look in your /etc/mysql/my.cnf at least on my system, there is no [mysqld] entry in the distributions my.cnf ! The guide says add these items to your my.cnf under the [mysqld] section. The guide should amend this and say: "If you do not have these directives in my.cnf you'll have to add them manually INCLUDING the [mysqld] section!" I can see how this can get very confusing, because each of these distros, and each of these open source packages like MySQL and tomcat9 have many different environments depending on who's flavor you're installing.
  7. Hey FunkyBlue, In my instance, I use 127.0.0.1 as the MySQL host since it's on the same machine. In that case, I didn't create the erauser beforehand. I arbitrarily picked the username erauser, so it would be unique from other db users. You could specify --db-user-username=ladygaga and the installer will create a MySQL user named ladygaga with full access to the MySQL database era_DB. If the script/installer can connect successfully to the MySQL instance with MySQL's root user, it SHOULD be able to create a DB, then add that user you've specified to that DB as full access. I think you're on the right path with hostname resolution / DNS! Something tells me that the script can't connect to your MySQL DB as the root MySQL user then it's just bombing.
  8. Hiya FunkyBlue, I believe I had this issue too when I was attempting to get ERA installed on Debian. The initial server install script connects to the empty MySQL server, then using MySQL's framework SHOULD create an ERA database user. I've installed ESET Protect 8 now three times, and sometimes it uses the MySQL ROOT user to make db queries to era_db, and other times it used the user it created on the install to make those queries! I think I've cracked the code to wit: sudo ./server-linux-x86_64.sh \ --skip-license \ --db-type="MySQL Server" \ --db-driver="MySQL ODBC 8.0 Driver" \ --db-hostname=your.host.name \ --db-port=3306 \ --db-admin-username=root \ ( This is the MySQL root user ) --db-admin-password=password \ ( beware of whitespace or characters which need to be escaped! I had a tough time with whitespace and escaped characters, this would have been set when you went through the MySQL installation on your system) --db-user-username=erauser \ ( This is the MySQL user ERA WANTS to create and use as the default user for it's era_DB I chose "erauser" ) --db-user-password=(erauser password - the script sets this) \ --server-root-password=(webconsole password - the script sets this) \ --cert-hostname="host, ipaddr, FQDN" I think one of the issues is that a lot of these variables, users, terms, and directives are REALLY close in name, leading to end user transposition in what they THINK ERA wants in those fields. At least that's what I've found, and so far the only way I've overcome was by brute force lol!
  9. Hey ESET Forums! I've been trying to deploy ESET Protect on Debian 10 x64 for a few days now. I believe I'm ALMOST there. I've got the Server, MySQL, ODBC, Tomcat9, AGENT, and WEBApp installed. It works after following the Linux Deployment guide, there are a few gotchas in the ODBC installation on Debian, the instructions cover Ubuntu fine, but for Debian, you just have to untar the ODBC and drop the libraries manually where they need to go then refresh with ldconfig. My problem is, that after following the install the default instance of Tomcat9 that ESET uses is then un-encrypted and listening on port 8080. It still works! I then struggled to insert a self signed certificate into the running Tomcat9 instance. It would be helpful if ESET could write up instructions for the masses on doing this. First off Tomcat9's certificate structure is mind melting with keytool. There are a LOT of gotchas with the certificate process. Well I FINALLY was able to install a self signed certificate into the Tomcat9 instance, and signed in ONCE and couldn't believe how overjoyed I was at overcoming that hurdle! On a second sign in, however, I started getting all sorts of hairy errors in the console such as: Failed to Obtain License syncronization status, Failed to load tags, etc! The whole thing is broken now! The tomcat9 logs have a ton of critical errors like this: [2021-02-11 16:01:04] [crit] Error executing GraphQL request! [2021-02-11 16:01:04] [crit] graphql.GraphQLException: No valid query found in request [2021-02-11 16:01:04] [crit] at graphql.kickstart.servlet.GraphQLPostInvocationInputParser.getGraphQLInvocationInput(GraphQLPostInvocationInputParser.java:44) Now I have a feeling that this is all certificate related, and somehow the connections to the MySQL DB are now sandbagged because of my self signed certificate. My questions are as follows: Does the tomcat9 instance that ERAServer uses, need to use the ERA generated certificates which are NOT-installed initially by ERA Protect Server install script? How can I use my own certificate to secure the tomcat9 instance after installing? Are the certificate alias names, or keyAlias names in the tomcat9 keystore somehow relevant to how ERAServer and need to be set to specific names to have it work? Lastly how can I recover this install? I've been banging my head against a wall for a while trying to secure tomcat9 with TLS on 8443! Additionally I'd like to add that the ESET documentation for the Linux install could be improved if they could expound on topics such as: 1) tomcat9 server.xml gotchas There's a lot of confusion about what kind of server instance or connection facility tomcat uses. Is it NIO, NIO2, APR. A little writeup on the proper server.xml Connector directive would be helpful! I found a KB6721 for ESET Remote Administrator 7.X for Windows, but it wasn't relevant for my install. I know why this information is so sparse, because the whole tomcat9 framework is vast and there are SO many conventions, a blurb about what ESET recommends for their tomcat9 instance would be helpful. For instance I spent hours looking up certificate imports against the keystore only to realize that tomcat9 now uses PCKS12 instead of JKS etc! ESET firming up their directives standards as it applies to tomcat9 with detailed instructions and pitfalls would be helpful! Thank you!
  10. I finally got ERA 6.0 installed, and I noticed the ESET Remote administration component is on the server now. I don't want any antivirus on the server itself, and would like to remove the ESET Remote Administration software from the server since I don't intend to manage the server from ERA6. Can this be removed without breaking ERA6 or any other parts of the ESET Server?
  11. Hello, I just recently purchased ESET NOD32 with the remote administrator option. I'd like to deploy the endpoint clients with the remote administrator. Although I cannot install the Remote Administrator. It hinges on the fact that it cannot seem to create the SQL database. A little backstory. We have a vascular hand scanner app that stores hand scans of employees in a Microsoft SQL database. So we're running Microsoft SQL Express 2012, I didn't want ESET Remote administrator installing SQL express, so I figure I'd manually create the database. If I MANUALLY create era_db, and create a username password combo as the owner, I can connect to it just fine with an ODBC Data source. However when I punch those credentials into the install script, it tells me that the database is either missing or corrupt! If I delete the database, then run the ERA Install, it will pass, and begin installing, but then it crashes when it gets to the "Running Database Scripts" part of the install. I've enabled diagnostic logging and it seems to fail here: Property(C): P_DIRECTORIES_TO_REMOVE = C:\ProgramData\ESET\RemoteAdministrator\Server|C:\Users\dave\AppData\Local\Temp\1\EsetRemoteAdminServer\ Property(C): P_BAD_USER_INPUT = Unable to connect to the database (error 0) - selected database driver is not correct Property(C): P_DIRECTORIES_TO_REMOVE_IF_EMPTY = C:\ProgramData\ESET\RemoteAdministrator|C:\ProgramData\ESET Property(C): P_DB_AUTHENTICATION_MODE_STATUS = OK Property(C): P_DB_NAME_OK = 1 Property(C): P_DATABASE_ALL_PARAM_CHECKED = 1 Property(C): P_DB_ADMIN_CONNECTION_STATUS = OK Property(C): P_DB_LONG_STATEMENT_EXECUTION_STATUS = OK Property(C): P_ALL_PARAM = 1 Property(C): P_DB_ADMIN_PASSWORD_OK = 1 Property(C): P_DB_USER_USERNAME_OK = 1 Property(C): P_DB_STATUS = DB_MISSING So my question is this, What ODBC drivers need to be loaded on the server. Currently it's Windows Server 2012, I have these SQL drivers: SQL Native Driver 2005, SQL Server 6.03, and SQL Server Native Client 11. What do I select when the ERA install asks me how I'd like to connect to the MSSQL database? SQL Server, SQL Client 10.0, or ODBC Driver 11 for SQL server? Should I create the database before hand? Or Give the ESET program a username that has create database privelages? I have confirmed that when I manually create the database, I can connect to it on Port 1433 and can connect ODBC connectors to it no problem. Something else seems to be stonewalling me! Any help would be appreciated. Thanks.
×
×
  • Create New...