Implement web installer module (#9)
Closed
Andrzej Wójcik (Tigase) opened 1 decade ago
Due Date
2014-08-22

When Tigase XMPP Server is started without configuration or when it is misconfigured it could deploy this module on HTTP server provided by Tigase HTTP API project to allow user to install or fix configuration using web forms instead of using installer or instead manual editing of files.

This could replace our current installer for Tigase XMPP Server.

Andrzej Wójcik (Tigase) commented 1 decade ago

I added implementation of setup module to HTTP API project so no we have HTTP based setup and configuration module available at /setup/ path of HTTP API web server. By default it would be http://localhost:8080/setup/

Access to this interface is protected in following way:

  • if AuthRepository is not configured then access is allowed (initial installation)

  • if it is accessed on localhost then access is allowed

  • if user is authenticated by jid and password as user from admins of Tigase XMPP Server then access is allowed

  • in other case access is denied

To check how it works you need to deploy and configure HTTP API component.

I think that it would be good, if someone who tested or created previous installer would look at this and check, if all needed things are in new web based installer.

Artur Hefczyc commented 1 decade ago

Andrzej Wójcik wrote:

I added implementation of setup module to HTTP API project so no we have HTTP based setup and configuration module available at /setup/ path of HTTP API web server. By default it would be http://localhost:8080/setup/

Access to this interface is protected in following way:

  • if AuthRepository is not configured then access is allowed (initial installation)
  • if it is accessed on localhost then access is allowed
  • if user is authenticated by jid and password as user from admins of Tigase XMPP Server then access is allowed
  • in other case access is denied

Ok, sounds good. I was also thinking of having admin account with password for the setup console stored in init.properties. But this is something we can work on at later time.

To check how it works you need to deploy and configure HTTP API component.

I think that it would be good, if someone who tested or created previous installer would look at this and check, if all needed things are in new web based installer.

Ok, I think this is a good task for Wojciech then. The way it should work, is that the Tigase binary build should contain a default init.properties file which enables HTTP API component. So a potential user downloads binary package, unpacks it, starts Tigase and goes to web browser to continue the server installation.

Basically, the user does not need to edit init.properties file to setup working server.

Artur Hefczyc commented 1 decade ago

I tested package from 12th Sept 2014 and it doesn't fully work.

Step to replicate:

  1. I took a binary package: http://build.tigase.org/nightlies/dists/2014-09-12/tigase-server-5.3.0-SNAPSHOT-b3671-dist-max.tar.gz

  2. Unpacked it to a new folder

  3. Run the server as normally

  4. (lots of exceptions in the log file and severe errors) this is more or less acceptable right now, but eventually we have to clean it up

  5. Then I run in browser: http://localhost:800/setup

  6. Got very nice page and started installer

  7. Everything worked more or less OK until I got to the page setting up database

  8. The database connection was unsuccessful and as a result database was not prepared. I tried for Derby and MySQL

  9. Another problem was, that, I was hoping to at least have init.properties file generated and wanted to generate database manually but the installer would not go to the last step, was jumping back to some step in configuration.

Overall it all worked quite well and looks very well. However, we have to polish the whole installation process to make sure it is successful.

Andrzej Wójcik (Tigase) commented 10 years ago

I checked installer once again and I think I know what could cause this issue. In old installer database was created while this current version assumes that database is create but schema needs to be loadad. If this was causing issue in tests then maybe it would be good to allow database creation as an option which would be checked by default? Idea behind forcing manual creation of database by user was that not all database engines support this (ie. in MSSQL this is rather difficult thing to do) and it would verify that name of database was passed correctly as database connection will fail if there is a mistake in db name, while in old approad user could get new database.

Database issue with Derby might be an issue with JDBC connection string which might force to use Derby as separate process, but I'm not sure about this as I'm not so familiar with Derby.

As for a lot of exceptions and entries with SEVERE level, I think I just reduced number of this entris which should solve this as well.

Artur Hefczyc commented 10 years ago

My 5 cents.

We definitely need the installer to create DB for at least some databases (as an option of course)): MySQL, Derby, PostgreSQL and MongoDB if possible. I want the process to be easy and smooth as the first impression is critical. At very least we need Derby to be fully automated.

wojciech.kapcia@tigase.net commented 10 years ago

Andrzej Wójcik wrote:

(…) In old installer database was created while this current version assumes that database is create but schema needs to be loadad. (…) Idea behind forcing manual creation of database by user was that not all database engines support this (ie. in MSSQL this is rather difficult thing to do) and it would verify that name of database was passed correctly as database connection will fail if there is a mistake in db name, while in old approad user could get new database.

Andrzej, because of problematic loading of MSSQL and the need to automatically re-create it (and also prepare it before in installer) I've taken and re-worked a bit custom tigase class build for installer (@TigaseInstallerDBHelper.java@) and included it in tigase-server repository (v. DBSchemaLoader.java) - it's far from being perfect but works and gets the job done so I think it can be used in the installer module - it will use the same schema files that are used by the installer and it will be easy to include any additional schemas (pubsub3, etc) if needed.

Andrzej Wójcik (Tigase) commented 10 years ago

I changed setup module to use DBSchemaLoader wrapped by SchemaLoader (new abstract class added to be able in future to create schema loader mechanism for MongoDB). I also modified DBSchemaLoader to be able to retrieve status of each operation which I needed to present on setup page.

wojciech.kapcia@tigase.net commented 10 years ago

With the latest nightly "database installation" step results in white page and there is following exception in the logs:

2014-10-14 13:08:44.115 [hostnames]        UserRepositoryMDImpl.getData()     WARNING:  Couldn't obtain user repository for domain: vhost-manager, not even default one!
2014-10-14 13:09:20.028 [Thread-153]       SetupServlet.service()             SEVERE:   exception processing request
java.lang.NullPointerException
        at tigase.http.setup.SetupServlet.processRequest(SetupServlet.groovy:118)
        at tigase.http.setup.SetupServlet.service(SetupServlet.groovy:75)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
        at tigase.http.java.RequestHandler.handle(RequestHandler.java:75)
        at com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:77)
        at sun.net.httpserver.AuthFilter.doFilter(AuthFilter.java:83)
        at com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:80)
        at sun.net.httpserver.ServerImpl$Exchange$LinkHandler.handle(ServerImpl.java:677)
        at com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:77)
        at sun.net.httpserver.ServerImpl$Exchange.run(ServerImpl.java:649)
        at sun.net.httpserver.ServerImpl$DefaultExecutor.execute(ServerImpl.java:158)
        at sun.net.httpserver.ServerImpl$Dispatcher.handle(ServerImpl.java:433)
        at sun.net.httpserver.ServerImpl$Dispatcher.run(ServerImpl.java:398)
        at java.lang.Thread.run(Thread.java:744)
Andrzej Wójcik (Tigase) commented 10 years ago

For me this was working fine so I checked propable cause and finally I found out that I had different step-8.html file in my tigase/setup directory in Tigase XMPP Server installation directory which was loaded instead of default one from Tigase HTTP API jars project. I updated step-8.html file in repository to template file used by my installation in which this step is working fine.

wojciech.kapcia@tigase.net commented 10 years ago

Loading schema works now, except for socks5 and pubsub:

Loading socks5 component schema	ERROR
Loading schema from file: mysql-socks5-schema.sql, URI: jdbc:mysql://localhost/tigasedb?user=root&password=root
null
Can't finalize: null
Loading PubSub component schema	ERROR
Loading schema from file: mysql-pubsub-schema-3.0.0.sql, URI: jdbc:mysql://localhost/tigasedb?user=root&password=root
null
Can't finalize: null
Andrzej Wójcik (Tigase) commented 10 years ago

I updated setup module part responsible for loading socks5 and pubsub schemas.

wojciech.kapcia@tigase.net commented 10 years ago

Works now, but there is still small issue - no matter which database name I provide it will always use dbName=tigasedb

Properties: [{dbHostname=localhost, logLevel=CONFIG, adminJID=admin123@atlantiscity, dbType=mysql, rootUser=root, dbPass=tigase, adminJIDpass=tigase, dbName=tigasedb, schemaVersion=5-1, rootPass=root, dbUser=tigase}]
Andrzej Wójcik (Tigase) commented 10 years ago

I fixed dbName issue, it was omited when I copied data from form to properties passed to DBSchemaLoader

wojciech.kapcia@tigase.net commented 10 years ago

web installer now works as the IzPack one.

issue 1 of 1
Type
New Feature
Priority
Normal
Assignee
RedmineID
2101
Issue Votes (0)
Watchers (0)
Reference
tigase/_server/tigase-http-api#9
Please wait...
Page is in error, reload to recover