Dmitriy,
I will check soon and see what can be done to overcome this. Yet, I still doubt that running Apache Ignite packed in DEB under Windows 10 WSL Ubuntu is a plausible user case. To be honest, I doubt that our packages are being downloaded and installed at all... > On 5 Jun 2018, at 21:26, Dmitriy Setrakyan <dsetrak...@apache.org> wrote: > > Petr, > > Were you ever able to successfully start an Ignite node from Ubuntu on > Windows 10? > > It looks like a node startup hangs for me. Here is the message I am getting > when bringing up a node in verbose mode: > > *[18:24:27,778][WARNING][main][TcpDiscoverySpi] Node has not been connected >> to topology and will repeat join process. Check remote nodes logs for >> possible error messages. Note that large topology may require significant >> time to start. Increase 'TcpDiscoverySpi.networkTimeout' configuration >> property if getting this message on the starting nodes >> [networkTimeout=5000]* > > > Just by looking how much I am struggling to bring up a node, I can only > imagine what our poor users are going through when trying this out. > > D. > > On Tue, Jun 5, 2018 at 2:06 AM, Petr Ivanov <mr.wei...@gmail.com> wrote: > >> Dmitriy, >> >> >> I’ve replaced root user requirement with ignite user requirement. It is >> necessary because after installation ignite user receive all Apache Ignite >> work directories ownership (to be able to write woking files there). >> In fact, Apache Ignite as a service is configured to run just under the >> same user — ignite. >> >> So — it is yes and no. Issuing systemctl command and editing configuration >> files at /etc/apache-ignite does require root permissions, however the >> Apache Ignite Java process itself runs under unprivileged user ignite with >> no password and no login shell, thus making running process significantly >> less susceptible to outside impact. >> And to be able to run Apache Ignite as a standalone process — it is enough >> to login as ignite user (as it is mentioned in documentation) and run >> ignite.sh as usual. >> >> >> >> >>> On 5 Jun 2018, at 08:00, Dmitriy Setrakyan <dsetrak...@apache.org> >> wrote: >>> >>> Petr, >>> >>> I think it was Denis who reworked the documentation. In any case, if you >>> see something lacking you can fix it. >>> >>> Just to clarify, are you suggesting that you don't have to be root to run >>> the Ignite process after the package install? >>> >>> D. >>> >>> On Mon, Jun 4, 2018 at 9:31 PM, Petr Ivanov <mr.wei...@gmail.com> wrote: >>> >>>>> 1. Remove the requirement to run Ignite scripts as root. This will be >> a >>>>> huge No in most environment and we should fix it. >>>> >>>> >>>>> There is already a ticket for point 1: >>>>> https://issues.apache.org/jira/browse/IGNITE-8695 < >>>> https://issues.apache.org/jira/browse/IGNITE-8695> >>>> >>>> 1. I am not the author of this part of instruction — someone, who >>>> completely reworked that section about running ignite as standalone >> process >>>> should also remove / rework the “require root permissions” part because >> in >>>> my version of documentation there was requirement to run as root, but >>>> requirement to run as ignite user (logining in into it with specified >>>> shell, because it is disabled by default — as it should be done for >> every >>>> service) due to packages’ postinstall scripts that assign ignite user >>>> permissions on all Apache Ignite directories. >>>> >>>> >>>>> 2. Add Ignite "bin" folder to PATH, so all Ignite scripts will be >>>>> executable without specifying the whole path name (not sure if it is >>>>> already done or not) >>>> >>>> 2. We should not. Instead, we have to symlink all required scripts from >>>> bin/ to /usr/bin, providing changes to scripts it selves, so that they >> can >>>> be called from /usr/bin as if from $IGNITE_HOME ('readlink' command to >> find >>>> real symlink location). >>>> >>>> >>>>> I do remember the multi-package approach was suggested as a solution to >>>>> trim down the size of the binary that is hosted by ASF. Since now the >>>>> binaries are hosted in Bintray, do we still have that issue? If it's >> fine >>>>> to preload and keep big binaries in Bintray then I would suggest us to >>>>> postpone the multi-package activities until there is a real demand. >>>> >>>> >>>> 3. The multi-package approach was also suggested for more accurate >>>> architecture and more flexible updates. And working with smaller >> packages >>>> on development stage is too more reliable and easy. >>>> Yes, we can postpone it (for how long?) but I’d like to insist on >> proposed >>>> layout (and reimplement it rather quickly), because ta least it shows >> our >>>> packages as more mature (no one ships theirs software in single monolith >>>> package, especially in official repositories). >>>> >>>> >>>>> - Make sqlline.sh callable from command line (PATH). E.g. symlink it as >>>>> /usr/bin/sqlline-ignite, make sure it works. >>>>> - Fix control.sh and visor-cmd, expose them too. >>>> >>>> 4. See p.2. Indeed they need to be fixes and exposes 'by the book’. >>>> >>>> >>>>> - Allow specifying of JDK implementation and JDK arguments for Apache >>>>> Ignite startup. Preferably on per configuration basis. >>>> >>>> 5. Agree. We need some kind of 'setenv.sh’ for user-side JDK >> configuration. >>>> >>>> >>>>> - Allow adding-removing "modules" to classpath of Ignite - again, >>>>> preferably on per configuration basis. E.g. what happens if I want to >>>> turn >>>>> ON geospatial/ >>>> >>>> 6. Agree, was thinking of it too, in form of 'a2enmod'-like utility for >>>> enabling / disabling optional libs and modules. >>>> >>>> >>>>> - [OPTIONAL] Ship Apache Ignite with a special config which only >> listens >>>> on >>>>> localhost. This is for lazy people who can get into trouble by >> installing >>>>> package without looking without security implications. >>>> >>>> 7. Arguable. Even if we create such config and put into delivery, there >> is >>>> no guarantee that user will read documentation about necessity of using >>>> this special config for security reasons. >>>> I would add BIG warning text to Ignite’s log about security implications >>>> of unprotected cluster. >>>> >>>> >>>>> With regards to splitting package, I think we could have a few of them >>>>> (a-i-core, a-i-doc, a-i-c++, a-i-.net) but I don't think we need to >> have >>>> a >>>>> half dozen of those right away. This was mostly realised as an >>>> antipattern. >>>> >>>> 8. I would at least removed benchmarks, docs and platforms from the core >>>> package. >> >>
