Announcement

Collapse
No announcement yet.

Switching to Postgres doesn't work for me (well)

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Switching to Postgres doesn't work for me (well)

    Hello,

    I am having a really rough time switching from derby to postgres.

    My server is Ubuntu 16.04 and so far, playing around with derby has not been an issue (http, https, java applet work).

    I installed postgres, created a db named derp, with the user name and password derp (same) and edited the conf to reflect what I thought was right (I will post it below):

    Code:
    # Mirth Connect configuration file
    
    # directories
    dir.appdata = /usr/local/mirthconnect/applicationdata
    dir.tempdata = ${dir.appdata}/temp
    
    # ports
    http.port = 8080
    https.port = 8443
    
    # password requirements
    password.minlength = 5
    password.minupper = 0
    password.minlower = 0
    password.minnumeric = 0
    password.minspecial = 0
    password.retrylimit = 0
    password.lockoutperiod = 0
    password.expiration = 0
    password.graceperiod = 0
    password.reuseperiod = 0
    password.reuselimit = 0
    
    # keystore
    keystore.path = ${dir.appdata}/keystore.jks
    keystore.storepass = 81uWxplDtB
    keystore.keypass = 81uWxplDtB
    keystore.type = JCEKS
    
    # server
    http.contextpath = /
    server.url = 10.100.140.250
    
    http.host = 10.100.140.250
    https.host = 10.100.140.250
    
    https.client.protocols = TLSv1.2,TLSv1.1
    https.server.protocols = TLSv1.2,TLSv1.1,SSLv2Hello
    https.ciphersuites = TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384,TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,TLS_DHE_DSS_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256,TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,TLS_DHE_DSS_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384,TLS_DHE_RSA_WITH_AES_256_CBC_SHA256,TLS_DHE_DSS_WITH_AES_256_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,TLS_DHE_RSA_WITH_AES_256_CBC_SHA,TLS_DHE_DSS_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256,TLS_DHE_RSA_WITH_AES_128_CBC_SHA256,TLS_DHE_DSS_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_DSS_WITH_AES_128_CBC_SHA,TLS_EMPTY_RENEGOTIATION_INFO_SCSV
    https.ephemeraldhkeysize = 2048
    
    # CORS headers
    server.api.accesscontrolalloworigin = *
    server.api.accesscontrolallowcredentials = false
    server.api.accesscontrolallowmethods = GET, POST, DELETE, PUT
    server.api.accesscontrolallowheaders = Content-Type
    server.api.accesscontrolexposeheaders =
    server.api.accesscontrolmaxage =
    
    # Determines whether or not channels are deployed on server startup.
    server.startupdeploy = true
    
    # Determines whether libraries in the custom-lib directory will be included on the server classpath.
    # To reduce potential classpath conflicts you should create Resources and use them on specific channels/connectors instead, and then set this value to false.
    server.includecustomlib = false
    
    # administrator
    administrator.maxheapsize = 512m
    
    # properties file that will store the configuration map and be loaded during server startup
    configurationmap.path = ${dir.appdata}/configuration.properties
    
    # options: derby, mysql, postgres, oracle, sqlserver
    database = postgres
    
    # examples:
    #       Derby           jdbc:derby:${dir.appdata}/mirthdb;create=true
    #       PostgreSQL      jdbc:postgresql://localhost:5432/mirthdb
    #       MySQL           jdbc:mysql://localhost:3306/mirthdb
    #       Oracle          jdbc:oracle:thin:@localhost:1521:DB
    #       SQLServer       jdbc:jtds:sqlserver://localhost:1433/mirthdb
    database.url = jdbc:postgresql://localhost:5432/derp
    
    # if using a custom driver, specify it here
    #database.driver =
    
    # maximum number of connections allowed for the connection pool
    database.max-connections = 20
    
    # database credentials
    database.username = derp
    database.password = derp
    After restarting the mirth service or rebooting I have the problem that I do not see anything at :8080 and :8443.

    Can anyone please point me in the right direction?

    Thank you for your time!

  • #2
    What do the server logs (logs/mirth.log) say?
    Step 1: JAVA CACHE...DID YOU CLEAR ...wait, ding dong the witch is dead?

    Nicholas Rupley
    Work: 949-237-6069
    Always include what Mirth Connect version you're working with. Also include (if applicable) the code you're using and full stacktraces for errors (use CODE tags). Posting your entire channel is helpful as well; make sure to scrub any PHI/passwords first.


    - How do I foo?
    - You just bar.

    Comment


    • #3
      Here are the logs of today:

      Code:
      ERROR 2017-08-11 10:49:13,628 [Main Server Thread] com.mirth.connect.server.Mirth: Error establishing connection to database, aborting startup. FATAL: no PostgreSQL user name specified in startup packet
      INFO  2017-08-11 10:49:13,630 [Shutdown Hook Thread] com.mirth.connect.server.Mirth: shutting down mirth due to normal request
      ERROR 2017-08-11 10:49:13,685 [Shutdown Hook Thread] com.mirth.connect.server.controllers.DefaultConfigurationController: Could not store property: category=core, name=channelDependencies
      org.apache.ibatis.exceptions.PersistenceException:
      ### Error updating database.  Cause: org.postgresql.util.PSQLException: FATAL: no PostgreSQL user name specified in startup packet
      ### Cause: org.postgresql.util.PSQLException: FATAL: no PostgreSQL user name specified in startup packet
              at org.apache.ibatis.exceptions.ExceptionFactory.wrapException(ExceptionFactory.java:23)
              at org.apache.ibatis.session.defaults.DefaultSqlSession.update(DefaultSqlSession.java:147)
              at org.apache.ibatis.session.defaults.DefaultSqlSession.insert(DefaultSqlSession.java:134)
              at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
              at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
              at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
              at java.lang.reflect.Method.invoke(Method.java:498)
              at org.apache.ibatis.session.SqlSessionManager$SqlSessionInterceptor.invoke(SqlSessionManager.java:282)
              at com.sun.proxy.$Proxy6.insert(Unknown Source)
              at org.apache.ibatis.session.SqlSessionManager.insert(SqlSessionManager.java:195)
              at com.mirth.connect.server.controllers.DefaultConfigurationController.saveProperty(DefaultConfigurationController.java:912)
              at com.mirth.connect.server.controllers.DefaultConfigurationController.setChannelDependencies(DefaultConfigurationController.java:990)
              at com.mirth.connect.server.controllers.DefaultConfigurationController.getChannelDependencies(DefaultConfigurationController.java:975)
              at com.mirth.connect.server.util.ChannelDependencyServerUtil.getDependencyGraph(ChannelDependencyServerUtil.java:26)
              at com.mirth.connect.server.util.ChannelDependencyServerUtil.getOrderedChannels(ChannelDependencyServerUtil.java:30)
              at com.mirth.connect.server.controllers.DonkeyEngineController.undeployChannels(DonkeyEngineController.java:405)
              at com.mirth.connect.server.controllers.DonkeyEngineController.stopEngine(DonkeyEngineController.java:225)
              at com.mirth.connect.server.Mirth.stopEngine(Mirth.java:362)
              at com.mirth.connect.server.Mirth.shutdown(Mirth.java:318)
              at com.mirth.connect.server.Mirth$ShutdownHook.run(Mirth.java:432)
      Caused by: org.postgresql.util.PSQLException: FATAL: no PostgreSQL user name specified in startup packet
              at org.postgresql.core.v3.ConnectionFactoryImpl.doAuthentication(ConnectionFactoryImpl.java:443)
              at org.postgresql.core.v3.ConnectionFactoryImpl.openConnectionImpl(ConnectionFactoryImpl.java:217)
              at org.postgresql.core.ConnectionFactory.openConnection(ConnectionFactory.java:52)
              at org.postgresql.jdbc.PgConnection.<init>(PgConnection.java:216)
              at org.postgresql.Driver.makeConnection(Driver.java:404)
              at org.postgresql.Driver.connect(Driver.java:272)
              at java.sql.DriverManager.getConnection(DriverManager.java:664)
              at java.sql.DriverManager.getConnection(DriverManager.java:208)
              at org.apache.ibatis.datasource.unpooled.UnpooledDataSource.doGetConnection(UnpooledDataSource.java:181)
              at org.apache.ibatis.datasource.unpooled.UnpooledDataSource.doGetConnection(UnpooledDataSource.java:176)
              at org.apache.ibatis.datasource.unpooled.UnpooledDataSource.getConnection(UnpooledDataSource.java:80)
              at org.apache.ibatis.datasource.pooled.PooledDataSource.popConnection(PooledDataSource.java:371)
              at org.apache.ibatis.datasource.pooled.PooledDataSource.getConnection(PooledDataSource.java:80)
              at org.apache.ibatis.transaction.jdbc.JdbcTransaction.openConnection(JdbcTransaction.java:131)
              at org.apache.ibatis.transaction.jdbc.JdbcTransaction.getConnection(JdbcTransaction.java:58)
              at org.apache.ibatis.executor.BaseExecutor.getConnection(BaseExecutor.java:279)
              at org.apache.ibatis.executor.SimpleExecutor.prepareStatement(SimpleExecutor.java:69)
              at org.apache.ibatis.executor.SimpleExecutor.doUpdate(SimpleExecutor.java:44)
              at org.apache.ibatis.executor.BaseExecutor.update(BaseExecutor.java:108)
              at org.apache.ibatis.executor.CachingExecutor.update(CachingExecutor.java:75)
              at org.apache.ibatis.session.defaults.DefaultSqlSession.update(DefaultSqlSession.java:145)
              ... 18 more
      INFO  2017-08-11 10:52:02,974 [Main Server Thread] com.mirth.connect.server.Mirth: Mirth Connect 3.5.0.8232 (Built on April 18, 2017) server successfully started.
      INFO  2017-08-11 10:52:02,977 [Main Server Thread] com.mirth.connect.server.Mirth: This product was developed by Mirth Corporation (http://www.mirthcorp.com) and its contributors (c)2005-2017.
      INFO  2017-08-11 10:52:02,978 [Main Server Thread] com.mirth.connect.server.Mirth: Running Java HotSpot(TM) 64-Bit Server VM 1.8.0_144 on Linux (4.4.0-87-generic, amd64), derby, with charset UTF-8.
      INFO  2017-08-11 10:52:02,978 [Main Server Thread] com.mirth.connect.server.Mirth: Web server running at http://127.0.1.1:8080/ and https://127.0.1.1:8443/
      INFO  2017-08-11 15:09:14,168 [Shutdown Hook Thread] com.mirth.connect.server.Mirth: shutting down mirth due to normal request
      INFO  2017-08-11 15:09:23,694 [Main Server Thread] com.mirth.connect.server.Mirth: Mirth Connect 3.5.0.8232 (Built on April 18, 2017) server successfully started.
      INFO  2017-08-11 15:09:23,696 [Main Server Thread] com.mirth.connect.server.Mirth: This product was developed by Mirth Corporation (http://www.mirthcorp.com) and its contributors (c)2005-2017.
      INFO  2017-08-11 15:09:23,696 [Main Server Thread] com.mirth.connect.server.Mirth: Running Java HotSpot(TM) 64-Bit Server VM 1.8.0_144 on Linux (4.4.0-87-generic, amd64), postgres, with charset UTF-8.
      INFO  2017-08-11 15:09:23,697 [Main Server Thread] com.mirth.connect.server.Mirth: Web server running at http://10.100.140.250:8080/ and https://10.100.140.250:8443/
      INFO  2017-08-11 15:17:12,941 [Shutdown Hook Thread] com.mirth.connect.server.Mirth: shutting down mirth due to normal request
      INFO  2017-08-11 15:17:21,890 [Main Server Thread] com.mirth.connect.server.Mirth: Mirth Connect 3.5.0.8232 (Built on April 18, 2017) server successfully started.
      INFO  2017-08-11 15:17:21,892 [Main Server Thread] com.mirth.connect.server.Mirth: This product was developed by Mirth Corporation (http://www.mirthcorp.com) and its contributors (c)2005-2017.
      INFO  2017-08-11 15:17:21,892 [Main Server Thread] com.mirth.connect.server.Mirth: Running Java HotSpot(TM) 64-Bit Server VM 1.8.0_144 on Linux (4.4.0-87-generic, amd64), postgres, with charset UTF-8.
      INFO  2017-08-11 15:17:21,893 [Main Server Thread] com.mirth.connect.server.Mirth: Web server running at http://10.100.140.250:8080/ and https://10.100.140.250:8443/
      Yersterday I had problems as well... but to put a long story short, I created a new and simple db (hence the role, db and pw being all the same).
      Last edited by Peanut; 08-11-2017, 06:49 AM. Reason: removing a detail in the cli

      Comment


      • #4
        Another quick detail I just now discovered is that I can reach the instance at :8334 but :8080 doesn't work... but now I can't log in with the default admin/admin credentials .

        Comment


        • #5
          Just switched back to derby and have a similar problem where :8443 works and :8080 doesn't. The default admin credentials however work.

          Forgot to mention I have version 3.5.0.8232 installed.

          Comment


          • #6
            anything I'm doing wrong with the postgres conf?

            Comment


            • #7
              It sounds similar to this thread from PSQL.

              https://forums.opensuse.org/showthre...27#post2774727
              HL7v2.7 Certified Control Specialist!

              Comment


              • #8
                Thanks for the tip. I double checked the postgres logs, and I just saw authenticating errors (compared to the opensuse thread). I then purged postgres from the system, reinstalled it and created a new db user.

                I also only edited the:
                Code:
                database
                Code:
                database.url
                Code:
                database.username and database.password
                fields and it started working from there.


                Should admins leave the following definitions as is?

                Code:
                http.contextpath = /
                server.url =
                
                http.host = 0.0.0.0
                https.host = 0.0.0.0

                Comment

                Working...
                X