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. > >
