On 13/01/2017 10:30, Pierre Smits wrote:
Ok. Thanks.

I guess one of the next steps will be to change the password of the admin userid to make it more secure.

Not an hard task, though:



On Fri, Jan 13, 2017 at 9:26 AM, Francesco Chicchiriccò <ilgro...@apache.org <mailto:ilgro...@apache.org>> wrote:

    Hi all,
    I honestly do not see the point of putting any effort (yet) in
    puppetizing the configurations on syncope-vm2.

    syncope-vm2 is the VM we are using to implement a PoC, not a
    production environment.

    For example, I had to install the OpenLDAP packages to load the
    ASF Directory dump, in order to have a reference external resource
    for Syncope. I would not expect this in a production machine.

    The work to be done there is currently about configuring Syncope
    (mainly via Admin UI) and possibly developing some extension
    classes, to be part of the sources hosted at


    with purpose of building a replacement for https://id.apache.org

    I expect such work not to be completed anytime son, partly because
    it is inherently complex, partly because it is done in my own
    spare time.

    I agree, indeed, that:

    1. leaving all ports open to the wild is not good (especially
    because there is currently an OpenLDAP instance loaded with the
    dump from the official ASF Directory), so I have configured
    iptables to refuse connections on all ports but SSH (see
    /root/iptables.sh, currently saved via iptables-persistence to
    survive restarts)

    At the moment I can easily work with SSH port forwarding; I expect
    to re-open the ports 80 and 443, to allow connections to

    * http://idm-poc.apache.org/syncope
    <http://idm-poc.apache.org/syncope>, redirecting to
    * http://idm-poc.apache.org/syncope-console
    <http://idm-poc.apache.org/syncope-console>, redirecting to
    * http://idm-poc.apache.org/syncope-enduser
    <http://idm-poc.apache.org/syncope-enduser>, redirecting to

    as already configured by Pierre.

    Note: I don't see any reason to enable the Syncope Swagger
    extension, hence it is perfectly expected that


    returns nothing.

    2. being the tomcat8 packages installed, there is almost no reason
    (but the unavailability of Tomcat 8.5 as deb package, but this is
    another story...) to use the manual Tomcat deployment under /opt,
    I will remove that soon


    On 12/01/2017 22:58, Pierre Smits wrote:


        Francesco didn't install the syncope wars in/on the puppet
        Tomcat, but did a new Tomcat installation in /opt.

        So we need to figure out how to do that correction there, or
        syncope in the puppet controlled Tomcat.

        On Thu, Jan 12, 2017 at 10:48 PM, Tony Stevenson
        <pct...@apache.org <mailto:pct...@apache.org>> wrote:

                On Jan 12, 2017, at 1:22 PM, Pierre Smits
                <mailto:pierre.sm...@gmail.com>> wrote:

                Please do not use the syncope implementation via the
                unencrypted tomcat port 8080/

            Then configure tomcat to only listen on loopback, or only
            allow access
            from the local interface then.  Better yet change the
            firewall rules. Or do
            both. ;)

            Assuming the VM is in puppet the firewall rules should be
            a few lines of

Francesco Chicchiriccò

Tirasa - Open Source Excellence

Member at The Apache Software Foundation
Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail

Reply via email to