My issue is the same as this: https://support.gluu.org/installation/3734/testing-new-install-of-300-fails-to-startstop-services-after-initial-install/ Is there a bug report for this yet?

Hi, Chris. Please do next commands in the container and share results here: - `# service oxauth status` - `# service identity status` - `# service idp status`

``` root@sso:~# service oxauth status Jetty running pid=24284 START_INI = /opt/gluu/jetty/oxauth/start.ini START_D = /opt/gluu/jetty/oxauth/start.d JETTY_HOME = /opt/jetty JETTY_BASE = /opt/gluu/jetty/oxauth JETTY_CONF = /opt/jetty/etc/jetty.conf JETTY_PID = /var/run/oxauth.pid JETTY_START = /opt/jetty/start.jar JETTY_LOGS = /opt/gluu/jetty/oxauth/logs JETTY_STATE = /opt/gluu/jetty/oxauth/oxauth.state CLASSPATH = JAVA = /opt/jre/bin/java JAVA_OPTIONS = -server -Xms256m -Xmx1084m -XX:+DisableExplicitGC -Dgluu.base=/etc/gluu -Dpython.home=/opt/jython -Dcatalina.base=/opt/gluu/jetty/oxauth -Djetty.logging.dir=/opt/gluu/jetty/oxauth/logs -Djetty.home=/opt/jetty -Djetty.base=/opt/gluu/jetty/oxauth -Djava.io.tmpdir=/opt/jetty-9.3/temp JETTY_ARGS = jetty.http.host=localhost jetty.http.port=8081 jetty.state=/opt/gluu/jetty/oxauth/oxauth.state jetty-logging.xml jetty-started.xml RUN_CMD = /opt/jre/bin/java -server -Xms256m -Xmx1084m -XX:+DisableExplicitGC -Dgluu.base=/etc/gluu -Dpython.home=/opt/jython -Dcatalina.base=/opt/gluu/jetty/oxauth -Djetty.logging.dir=/opt/gluu/jetty/oxauth/logs -Djetty.home=/opt/jetty -Djetty.base=/opt/gluu/jetty/oxauth -Djava.io.tmpdir=/opt/jetty-9.3/temp -jar /opt/jetty/start.jar jetty.http.host=localhost jetty.http.port=8081 jetty.state=/opt/gluu/jetty/oxauth/oxauth.state jetty-logging.xml jetty-started.xml ``` ``` root@sso:~# service identity status Jetty NOT running START_INI = /opt/gluu/jetty/identity/start.ini START_D = /opt/gluu/jetty/identity/start.d JETTY_HOME = /opt/jetty JETTY_BASE = /opt/gluu/jetty/identity JETTY_CONF = /opt/jetty/etc/jetty.conf JETTY_PID = /var/run/identity.pid JETTY_START = /opt/jetty/start.jar JETTY_LOGS = /opt/gluu/jetty/identity/logs JETTY_STATE = /opt/gluu/jetty/identity/identity.state CLASSPATH = JAVA = /opt/jre/bin/java JAVA_OPTIONS = -server -Xms256m -Xmx723m -XX:+DisableExplicitGC -Dgluu.base=/etc/gluu -Dcatalina.base=/opt/gluu/jetty/identity -Dpython.home=/opt/jython -Dorg.eclipse.jetty.server.Request.maxFormContentSize=50000000 -Djetty.logging.dir=/opt/gluu/jetty/identity/logs -Djetty.home=/opt/jetty -Djetty.base=/opt/gluu/jetty/identity -Djava.io.tmpdir=/opt/jetty-9.3/temp JETTY_ARGS = jetty.http.host=localhost jetty.http.port=8082 jetty.state=/opt/gluu/jetty/identity/identity.state jetty-logging.xml jetty-started.xml RUN_CMD = /opt/jre/bin/java -server -Xms256m -Xmx723m -XX:+DisableExplicitGC -Dgluu.base=/etc/gluu -Dcatalina.base=/opt/gluu/jetty/identity -Dpython.home=/opt/jython -Dorg.eclipse.jetty.server.Request.maxFormContentSize=50000000 -Djetty.logging.dir=/opt/gluu/jetty/identity/logs -Djetty.home=/opt/jetty -Djetty.base=/opt/gluu/jetty/identity -Djava.io.tmpdir=/opt/jetty-9.3/temp -jar /opt/jetty/start.jar jetty.http.host=localhost jetty.http.port=8082 jetty.state=/opt/gluu/jetty/identity/identity.state jetty-logging.xml jetty-started.xml ``` ``` root@sso:~# service idp status Jetty NOT running START_INI = /opt/gluu/jetty/idp/start.ini START_D = /opt/gluu/jetty/idp/start.d JETTY_HOME = /opt/jetty JETTY_BASE = /opt/gluu/jetty/idp JETTY_CONF = /opt/jetty/etc/jetty.conf JETTY_PID = /var/run/idp.pid JETTY_START = /opt/jetty/start.jar JETTY_LOGS = /opt/gluu/jetty/idp/logs JETTY_STATE = /opt/gluu/jetty/idp/idp.state CLASSPATH = JAVA = /opt/jre/bin/java JAVA_OPTIONS = -server -Xms256m -Xmx723m -XX:+DisableExplicitGC -Dgluu.base=/etc/gluu -Dcatalina.base=/opt/gluu/jetty/idp -Djetty.logging.dir=/opt/gluu/jetty/idp/logs -Djetty.home=/opt/jetty -Djetty.base=/opt/gluu/jetty/idp -Djava.io.tmpdir=/opt/jetty-9.3/temp JETTY_ARGS = jetty.http.host=localhost jetty.http.port=8086 jetty.state=/opt/gluu/jetty/idp/idp.state jetty-logging.xml jetty-started.xml RUN_CMD = /opt/jre/bin/java -server -Xms256m -Xmx723m -XX:+DisableExplicitGC -Dgluu.base=/etc/gluu -Dcatalina.base=/opt/gluu/jetty/idp -Djetty.logging.dir=/opt/gluu/jetty/idp/logs -Djetty.home=/opt/jetty -Djetty.base=/opt/gluu/jetty/idp -Djava.io.tmpdir=/opt/jetty-9.3/temp -jar /opt/jetty/start.jar jetty.http.host=localhost jetty.http.port=8086 jetty.state=/opt/gluu/jetty/idp/idp.state jetty-logging.xml jetty-started.xml ```

Thanks, now please try to run `# service identity start` and share any errors it will produce in logs.

No error. It starts fine and Gluu works again. The problem is that this needs to be done each time the Gluu server is restarted.

Ok, good. You can use it as a workaround for now, then. Thanks for reporting it, we'll look into it.

There is still something that is not starting up OK. oxauth, identity, and idp services are all running, but I am getting a "Service Unavailable" when trying to redirect to the saml SSO service I set up. This URL: https://myorg.com/idp/profile/SAML2/Redirect/SSO Is there another work around to get this working? It does not give me issues after a new installation, only when I reboot or restart the gluu server. EDIT: The following needs to be done after each reboot: ``` cd /etc/init.d ./identity stop ./oxauth stop ./solserver stop ./idp stop ./idp start ./solserver start ./oxauth start ./identity start ```

For SAML to work, atm you need to always add Custom Relying party configuration to TRs you create. Please follow guide [here](https://gluu.org/docs/ce/3.0.1/admin-guide/saml/#add-trust-relationship)

I've already done that. It is some sort of bug that will not start the services up correctly. The work around is to perform the following after each reboot: ``` cd /etc/init.d ./identity stop ./oxauth stop ./solserver stop ./idp stop ./idp start ./solserver start ./oxauth start ./identity start ``` Also, not sure if this is related, but when ever I create or update a TR, I get the following error: ``` failed to update shibboleth v3 configuration ``` It seems to add the TR to the gui though so I think it's working... Although nothing is added to metadata-providers.xml, but it's unclear if something is, or if that needs to be done manually.

Thanks for the update, Chris. The fix for services' startup bug will be added to Gluu CE 3.0.2 which is about to be released. We'll make sure that Shibboleth is operational after Gluu service's restart

> Although nothing is added to metadata-providers.xml This is a known issue and adding Custom RP config is supposed to be a workaround for it. TR for what SP you are trying to create?

I'm trying to set up Google SSO, but having a really hard time :( My metadata is now showing up in metadata-providers.xml, but I'm still getting this error: ``` 2017-03-08 21:20:14,698 - INFO [org.opensaml.saml.common.binding.impl.SAMLMetadataLookupHandler:128] - Message Handler: No metadata returned for google.com in role {urn:oasis:names:tc:SAML:2.0:metadata}SPSSODescriptor with protocol urn:oasis:names:tc:SAML:2.0:protocol 2017-03-08 21:20:14,701 - WARN [net.shibboleth.idp.profile.impl.SelectProfileConfiguration:111] - Profile Action SelectProfileConfiguration: Profile http://shibboleth.net/ns/profiles/saml2/sso/browser is not available for relying party configuration shibboleth.UnverifiedRelyingParty 2017-03-08 21:20:14,704 - WARN [org.opensaml.profile.action.impl.LogEvent:76] - An error event occurred while processing the request: InvalidProfileConfiguration ``` I do see the this in metadata-providers.xml: ``` <MetadataProvider id="SiteSP2" xsi:type="FilesystemMetadataProvider" metadataFile="/opt/shibboleth-idp/metadata/CF96E7FC3EAFCC250002BF4DF6EE00062CBE3F63-sp-metadata.xml"> ``` CF96E7FC3EAFCC250002BF4DF6EE00062CBE3F63-sp-metadata.xml seems to link to my google metadata which shows this: ``` <EntityDescriptor entityID="google.com/a/myorg.com" xmlns="urn:oasis:names:tc:SAML:2.0:metadata"> <SPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"> <NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:email</NameIDFormat> <AssertionConsumerService index="1" Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://www.google.com/a/myorg.com/acs" ></AssertionConsumerService> </SPSSODescriptor> </EntityDescriptor> ``` Is there something wrong with the metadata I uploaded?

We are checking our Google SAML TR doc, there are some issues with the procedure in CE 3.0 You can search for active tickets on the subject and track status of the issue there.

Hello, 08 Mar 2017 at 10:03 p.m. CET Aliaksandr Samuseu staff wrote: > The fix for services' startup bug will be added to Gluu CE 3.0.2 which is about to be released. In the mean time could you give a workaround to fix that? It seems to be due to the fact that oxauth starts well before solserver (slapd) and thus cannot load its configuration, and that all other jetty based services do not start (identity, oxauth-rp). There are installation errors related to this in /install/community-edition-setup/setup_error.log: ``` 19:22:11 05/09/17 INFO: ext initialised in ${jetty.base}/start.ini INFO: logging initialised in ${jetty.base}/start.ini INFO: server initialised (transitively) in ${jetty.base}/start.ini INFO: http initialised in ${jetty.base}/start.ini INFO: http-forwarded initialised in ${jetty.base}/start.ini INFO: deploy initialised in ${jetty.base}/start.ini INFO: jsp initialised in ${jetty.base}/start.ini MKDIR: ${jetty.base}/logs MKDIR: ${jetty.base}/webapps INFO: Base directory was modified 19:22:11 05/09/17 insserv: script identity: service jetty already provided! insserv: exiting now! update-rc.d: error: insserv rejected the script header 19:22:12 05/09/17 INFO: logging initialised in ${jetty.base}/start.ini INFO: server initialised (transitively) in ${jetty.base}/start.ini INFO: http initialised in ${jetty.base}/start.ini INFO: http-forwarded initialised in ${jetty.base}/start.ini INFO: deploy initialised in ${jetty.base}/start.ini INFO: jsp initialised in ${jetty.base}/start.ini MKDIR: ${jetty.base}/logs MKDIR: ${jetty.base}/webapps INFO: Base directory was modified 19:22:12 05/09/17 insserv: script oxauth-rp: service jetty already provided! insserv: exiting now! update-rc.d: error: insserv rejected the script header ``` I tried a little bit to change the /etc/rc*.d/ ordering, without success: on Debian Jessie there is systemd but systemd is not easy to control in a chroot environment.

Hi, Dominique. There shouldn't be that much difference in configuring systemd inside container. It's a basic Linux administration task, I don't think there are some notable specifics in case of container. Please check those (possibly other their) guides: [https://www.digitalocean.com/community/tutorials/understanding-systemd-units-and-unit-files](https://www.digitalocean.com/community/tutorials/understanding-systemd-units-and-unit-files) [https://www.digitalocean.com/community/tutorials/systemd-essentials-working-with-services-units-and-the-journal](https://www.digitalocean.com/community/tutorials/systemd-essentials-working-with-services-units-and-the-journal) [https://www.digitalocean.com/community/tutorials/how-to-use-systemctl-to-manage-systemd-services-and-units](https://www.digitalocean.com/community/tutorials/how-to-use-systemctl-to-manage-systemd-services-and-units) Locate Gluu services' configuration files, looking up under `/etc/systemd/system/` should yield them. In "Unit" sections of `oxauth`, `idp` and `identity` service files make sure that `openldap` service's name is mentioned in the **"After="** and **"Requires="** fields, like in example below (which is taken from 2.4.4 instance which uses **OpenDJ** instead of **OpenLDAP** and **Tomcat** instead of **Jetty**; in your case there should be a separate service for each component, not just a general Jetty service): ``` [Unit] Description=Tomcat Servlet Container Requires=opendj.service After=syslog.target opendj.service ```

Thanks for your answer: > There shouldn't be that much difference in configuring systemd inside container. Actually there are major differences: for example running the command systemctl in a chrooted environment causes an error message: ``` % ischroot ; echo $? 0 % systemctl list-dependencies Running in chroot, ignoring request. ``` It is not straightforward to manage systemd in a chrooted environment and some people are using that as an argument against systemd; cf.: http://0pointer.de/blog/projects/changing-roots https://superuser.com/questions/688733/start-a-systemd-service-inside-chroot/972940#answer-1208366 In any case because for gluu 3.0.1 CE under Debian the setup.py installer is not using systemd there is nothing in the /etc/systemd/system/ directory relating directly to gluu tools: ``` % find /etc/systemd/system /etc/systemd/system /etc/systemd/system/multi-user.target.wants /etc/systemd/system/multi-user.target.wants/remote-fs.target /etc/systemd/system/multi-user.target.wants/rsyslog.service /etc/systemd/system/multi-user.target.wants/memcached.service /etc/systemd/system/multi-user.target.wants/cron.service /etc/systemd/system/reboot.target.wants /etc/systemd/system/reboot.target.wants/hwclock-save.service /etc/systemd/system/halt.target.wants /etc/systemd/system/halt.target.wants/hwclock-save.service /etc/systemd/system/syslog.service /etc/systemd/system/poweroff.target.wants /etc/systemd/system/poweroff.target.wants/hwclock-save.service /etc/systemd/system/getty.target.wants /etc/systemd/system/getty.target.wants/getty@tty1.service % grep -rl ox /etc/systemd; echo $? 1 ``` On the containing system systemd did a conversion of the gluu init script: ``` cat /run/systemd/generator.late/gluu-server-3.0.1.service # Automatically generated by systemd-sysv-generator [Unit] SourcePath=/etc/init.d/gluu-server-3.0.1 Description=LSB: This shell script takes care of starting and stopping After=all.target [Service] Type=forking Restart=no TimeoutSec=5min IgnoreSIGPIPE=no KillMode=process GuessMainPID=no RemainAfterExit=yes ExecStart=/etc/init.d/gluu-server-3.0.1 start ExecStop=/etc/init.d/gluu-server-3.0.1 stop ``` But there is no such thing in the chrooted environment: ``` % ls /run/systemd/ was-enabled % cat /run/systemd/was-enabled getty@tty1.service remote-fs.target ``` So during startup the chrooted system seems to rely on LSB style init scripts, but I failed to change the behavior by changing the ordering in rc[2345].d or the dependencies in the scripts, hence my question: - What did you or will you do in gluu 3.0.2 CE to fix startup problems (i.e. solserver starting after oxauth, and identity and oxauth-rp not starting)? and a sub question: - did you succeed with a clean install under Debian Jessie to avoid the LSB jetty init script clashing issues (reported by /usr/sbin/update-rc.d), mentioned in my initial post, which are the cause for identity and oxauth-rp not starting?

Hi, Dominique. >did you succeed with a clean install under Debian Jessie to avoid the LSB jetty init script clashing issues (reported by /usr/sbin/update-rc.d), mentioned in my initial post, which are the cause for identity and oxauth-rp not starting? Some tests of basic functionality were conducted for Debian 8.4. What version do you use in your setup? I'll try to do a test setup in the latest Debian 8 distro and will get back to you.

Hi, > What version do you use in your setup? ``` % head -1 /etc/os-release PRETTY_NAME="Debian GNU/Linux 8 (jessie)" % uname -a Linux op.example.foo 3.16.0-4-amd64 #1 SMP Debian 3.16.39-1+deb8u2 (2017-03-07) x86_64 GNU/Linux ``` The problem with **/usr/sbin/update-rc.d** is that all three jetty based init scripts declare the service name as _jetty_ so after the first script is installed (_oxauth_) it complains that the script for _jetty_ is already installed for the next tools, namely _identity_ and _oxauth-rp_. By the way the 3.0.1 **setup.py** script categorizes Debian as non _systemd_ enabled, but in fact Debian 8 does use _systemd_ by default.

Hi Chris and Dominique, How is it going with you? Still facing problems?

We actually choose to use ADFS instead of Gluu. I really wanted to like Gluu and tried very hard to implement it, but there were just too many bugs involved with even the simplest of things to make me feel uncomfortable deploying it. If anyone from Gluu would like to reach out to me with my experience and input, I would be happy to talk to them about it.

Chris, That's a pity. We are sorry about that. We will definitely reach back to you to grab your experience and suggestions.

Hello, the restart problem is still there on our installation of the Gluu server: as stated above the usual mechanisms I know to control the ordering of the start of applications do not work (order by number or by dependencies of the installed LSB rc scripts + not found a way to do it with systemd). I was waiting for the release of Gluu 3.0.2 CE to see how the new distribution tackles the issue (either with systemd or LSB rc scripts) on Debian 8.

Thanks Dominique. 3.0.2 is about to release.... BTW, you are using Debian 8.0?

Hello, sorry for the late answer: ``` # lsb_release -a No LSB modules are available. Distributor ID: Debian Description: Debian GNU/Linux 8.7 (jessie) Release: 8.7 Codename: jessie ```