Credential manager installation doesn't survive reboot

By: Jeff E Mandel user 30 Apr 2018 at 11:18 a.m. CDT

15 Responses
Jeff E Mandel gravatar
I've been trying to install credential manager all weekend with incomplete luck. I have a fresh Virtual Box Ubuntu 16.04 appliance configured per instructions. I've installed gluu-server-3.1.2 on it and it comes up fine, and survives reboot. I install gluu-server-ext-3.1.2 on it using symas ldap and the builtin oxd, configure it, and it works. I made the changes to /etc/init.d/gluu-server-3.1.2 as noted in the oxd preparation. I reboot, and get the 503: service unavailable. I've done this twice with the same result. The only clues are: ``` grep ERROR oxauth.log 2018-04-30 14:10:37,355 ERROR [qtp2008017533-18] [xdi.oxauth.authorize.ws.rs.AuthorizeRestWebServiceImpl] (AuthorizeRestWebServiceImpl.java:825) - Failed to load session from LDAP by session_id: 'e7a1fbbd-6d5e-4fff-ab45-144ddca1fec2' grep ERROR oxtrust.log 2018-04-30 13:53:40,100 ERROR [qtp985655350-14] [com.sun.faces.context.flash.ELFlash] (ELFlash.java:1218) - JSF1094: Could not decode flash data from incoming cookie value Invalid characters in decrypted value. Processing will continue, but the flash is unavailable for this request. ``` Additionally, looking at the first few lines of the oxauth.log after restart: ``` 2018-04-30 15:12:18,902 WARN [main] [org.jboss.weld.xml.BeansXmlHandler] (BeansXmlHandler.java:397) - WELD-001208: Error when validating file:/opt/jetty-9.3/temp/jetty-localhost-8081-oxauth.war-_oxauth-any-6427953652035764302.dir/webapp/WEB-INF/classes/META-IN F/beans.xml@6 against xsd. cvc-complex-type.4: Attribute 'bean-discovery-mode' must appear on element 'beans'. ``` Looking at beans.xml: ``` more beans.xml <!-- Marker file indicating CDI should be enabled --> <beans xmlns="http://xmlns.jcp.org/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation=" http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/beans_1_1.xsd"> </beans> ``` Googling the error message, it seems like bean-discovery-mode="all" (or annotated) should be specified in the declaration of beans, but looking at versions of the file from my working appliance (yes, I keep backups!), the file hasn't changed, the warning about beans is there, but the appliance boots. Any suggestions?
Ubuntu 16.04 Oxd 3.1.2 Ubuntu 16.04
closed

Answers

By Jose Gonzalez staff 30 Apr 2018 at 2:48 p.m. CDT

Copy
Jose Gonzalez gravatar
Hi there, The errors you are showing are not related to credmanager or oxd actually. The one about `beans.xml` is a warning only. The severity of a message is displayed in uppercase just after the timestamp. The 503 error you are having may occur when the front http server (Apache) cannot communicate with the backend application. So it seems it's down. Can you verify the following: - The app is running (the port of credmanager is 8091) - oxd is running (the port used in default oxd installation is 8099) - You can login to oxTrust (a sanity check that oxAuth is fine) Also please attach a relevant portion of your `cred-manager.log` (click [here](https://gluu.org/docs/creds/administration/admin-console/#logging) for more info).

By Jeff E Mandel user 30 Apr 2018 at 3:30 p.m. CDT

Copy
Jeff E Mandel gravatar
Here is the relevant output of lsof: ``` java 1135 jetty 197u IPv6 16338 0t0 TCP localhost:8082 (LISTEN) java 1397 jetty 193u IPv6 17105 0t0 TCP localhost:tproxy (LISTEN) java 1671 jetty 21u IPv6 17199 0t0 TCP localhost:8099 (LISTEN) java 1711 jetty 143u IPv6 17205 0t0 TCP localhost:44050->localhost:1636 (ESTABLISHED) ``` Something seems to be alive: ``` curl localhost:8082 <html> <head> <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1"/> <title>Error 404 </title> </head> <body> <h2>HTTP ERROR: 404</h2> <p>Problem accessing /. Reason: <pre> Not Found</pre></p> <hr /><a href="http://eclipse.org/jetty">Powered by Jetty:// 9.3.15.v20161220</a><hr/> </body> </html> curl localhost:8099 curl: (52) Empty reply from server ``` The cred-manager.log shows it counting down on 30 tries to get the acr list from oxauth: ``` Could not retrieve the list of acrs supported by this server: Server returned HTTP response code: 503 for URL: https://gluu.jeffmandel.org/.well-known/openid-configuration ``` Not surprising, as oxauth has failed to start. I understand that the beans thing is a warning; I have a teenage son who ignores warnings reflexively. It seems like an easy enough thing to patch, and it would make the oxauth.log a lot shorter.

By Jose Gonzalez staff 30 Apr 2018 at 4:29 p.m. CDT

Copy
Jose Gonzalez gravatar
Your Gluu installation seems broken. Here is the output of `netstat -nltp` of an installation simmilar to yours in ubuntu: ``` Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 127.0.0.1:1636 0.0.0.0:* LISTEN 6613/slapd tcp 0 0 127.0.0.1:11211 0.0.0.0:* LISTEN 14444/memcached tcp6 0 0 :::80 :::* LISTEN 14766/apache2 tcp6 0 0 127.0.0.1:8081 :::* LISTEN 3468/java tcp6 0 0 127.0.0.1:8082 :::* LISTEN 3486/java tcp6 0 0 :::443 :::* LISTEN 14766/apache2 tcp6 0 0 127.0.0.1:8091 :::* LISTEN 14673/java tcp6 0 0 :::8099 :::* LISTEN 474/java ``` It's likely your `/etc/init.d/gluu-server-3.1.2` is messed up. Here is a link to a working one which already has the [changes](https://gluu.org/docs/creds/administration/installation/#oxd-preparation) suggested by the installation docs: https://github.com/GluuFederation/community-edition-package/blob/version_3.1.2/package/initd/gluu-server#L147

By Jeff E Mandel user 01 May 2018 at 5:26 a.m. CDT

Copy
Jeff E Mandel gravatar
``` sudo diff gluu-server-3.1.2.txt /etc/init.d/gluu-server-3.1.2 176c176 < if [ "`ps aux | grep $serviceName | grep -v grep | grep -i gluu`" != "" ]; then --- > if [ "`ps aux | grep $serviceName | grep -v grep | grep -i -E '(gluu|oxd)'`" != "" ]; then ``` I changed that and no improvement.

By Jose Gonzalez staff 01 May 2018 at 8:45 a.m. CDT

Copy
Jose Gonzalez gravatar
Jeff, To install or **use** cred-manager you have to fulfil the [requirements](https://gluu.org/docs/creds/administration/installation/#requirements). It looks like you are stuck at first one. Please ensure you have a stable environment beforehand. It's strange that your Gluu Server has failed upon reboot. I'd suggest to reinstall it on a fresh machine, and once you are sure it's functional, make a backup of it and proceed with cred-manager. If you have any problem in the first step you can open a separate ticket for assistance. Here are the relevant [docs](https://gluu.org/docs/ce/installation-guide/).

By Jeff E Mandel user 01 May 2018 at 9:25 a.m. CDT

Copy
Jeff E Mandel gravatar
I think I pointed out that I installed gluu-server-3.1.2 on a fresh Ubuntu 16.04 VM, had it working, rebooted, still had it working, installed credential-manager, had it working, rebooted, and now can't get it to work. I've done this twice. I'm happy to do it a third time, but I predict I'll have the same result. I've tried shutting down individual services and restarting them in the chroot without any luck. I'm guessing it's something like a config file that the installation of cred-manager corrupts. Can we start looking at that?

By Jose Gonzalez staff 02 May 2018 at 7:19 a.m. CDT

Copy
Jose Gonzalez gravatar
Hi Jeff, Of course I noticed it worked for you at the beginning. Just making sure you followed the standard procedures to install... actually the cred-manager installer has no overlaps with oxauth: It comes with the oxd's .deb and installs it, and also copies the app's .war file and setups a new service. To start, can you attach setup logs for both gluu and cred-manager. Find them at `/install/community-edition`. They are called `setup.log` and `setup_cred_mgr.log`. Also their corresponding error logs (they are suffixed with `_error` or so).

By Jeff E Mandel user 05 May 2018 at 11:56 a.m. CDT

Copy
Jeff E Mandel gravatar
I started fresh again. I installed and configured gluu-server-3.1.2. Here is the install error log: ``` cat setup_error.log 16:05:31 05/05/18 Installing Gluu Server 16:07:55 05/05/18 Generating RSA private key, 2048 bit long modulus .................+++ ........+++ e is 65537 (0x10001) 16:07:55 05/05/18 writing RSA key 16:07:55 05/05/18 Signature ok subject=/C=US/ST=PA/L=Media/O=jeffmandel.org/CN=gluu.jeffmandel.org/emailAddress=jeffemandel@jeffmandel.org Getting Private key 16:07:55 05/05/18 Certificate was added to keystore 16:07:55 05/05/18 Generating RSA private key, 2048 bit long modulus ..................................+++ ...............................................+++ e is 65537 (0x10001) 16:07:55 05/05/18 writing RSA key 16:07:55 05/05/18 Signature ok subject=/C=US/ST=PA/L=Media/O=jeffmandel.org/CN=gluu.jeffmandel.org/emailAddress=jeffemandel@jeffmandel.org Getting Private key 16:07:55 05/05/18 Certificate was added to keystore 16:07:55 05/05/18 Generating RSA private key, 2048 bit long modulus ...............................................................+++ ..+++ e is 65537 (0x10001) 16:07:55 05/05/18 writing RSA key 16:07:55 05/05/18 Signature ok subject=/C=US/ST=PA/L=Media/O=jeffmandel.org/CN=gluu.jeffmandel.org/emailAddress=jeffemandel@jeffmandel.org Getting Private key 16:07:56 05/05/18 Certificate was added to keystore 16:07:56 05/05/18 Generating RSA private key, 2048 bit long modulus ................................................................................................................+++ ........................................................................................................................................................+++ e is 65537 (0x10001) 16:07:56 05/05/18 writing RSA key 16:07:56 05/05/18 Signature ok subject=/C=US/ST=PA/L=Media/O=jeffmandel.org/CN=gluu.jeffmandel.org/emailAddress=jeffemandel@jeffmandel.org Getting Private key 16:07:56 05/05/18 Certificate was added to keystore 16:07:56 05/05/18 Generating RSA private key, 2048 bit long modulus .............................................................................+++ .....................................................................................+++ e is 65537 (0x10001) 16:07:56 05/05/18 writing RSA key 16:07:56 05/05/18 Signature ok subject=/C=US/ST=PA/L=Media/O=jeffmandel.org/CN=gluu.jeffmandel.org/emailAddress=jeffemandel@jeffmandel.org Getting Private key 16:07:57 05/05/18 Certificate was added to keystore 16:07:57 05/05/18 Generating RSA private key, 2048 bit long modulus ..............................................................+++ ............................+++ e is 65537 (0x10001) 16:07:57 05/05/18 writing RSA key 16:07:57 05/05/18 Signature ok subject=/C=US/ST=PA/L=Media/O=jeffmandel.org/CN=localhost/emailAddress=jeffemandel@jeffmandel.org Getting Private key 16:07:57 05/05/18 Certificate was added to keystore 16:07:57 05/05/18 Generating RSA private key, 2048 bit long modulus .....+++ .............................................+++ e is 65537 (0x10001) 16:07:57 05/05/18 writing RSA key 16:07:57 05/05/18 Signature ok subject=/C=US/ST=PA/L=Media/O=jeffmandel.org/CN=localhost/emailAddress=jeffemandel@jeffmandel.org Getting Private key 16:07:57 05/05/18 Certificate was added to keystore 16:07:57 05/05/18 Entry for alias gluu.jeffmandel.org successfully imported. Import command completed: 1 entries successfully imported, 0 entries failed or cancelled 16:07:58 05/05/18 Entry for alias gluu.jeffmandel.org successfully imported. Import command completed: 1 entries successfully imported, 0 entries failed or cancelled 16:07:58 05/05/18 Entry for alias gluu.jeffmandel.org successfully imported. Import command completed: 1 entries successfully imported, 0 entries failed or cancelled 16:08:28 05/05/18 Running in chroot, ignoring request. 16:08:33 05/05/18 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: servlets initialised in ${jetty.base}/start.ini INFO: deploy initialised in ${jetty.base}/start.ini INFO: jsp initialised in ${jetty.base}/start.ini INFO: websocket initialised in ${jetty.base}/start.ini MKDIR: ${jetty.base}/logs MKDIR: ${jetty.base}/webapps INFO: Base directory was modified 16:08:34 05/05/18 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 INFO: websocket initialised in ${jetty.base}/start.ini MKDIR: ${jetty.base}/logs MKDIR: ${jetty.base}/webapps INFO: Base directory was modified ``` I can access the appliance and it seems to work. Now I install cred-manager. Here is the log: ``` 16:18:05 05/05/18 Removed ./setup_cred_mgr.log 16:18:05 05/05/18 Removed ./setup_cred_mgr_error.log 16:18:05 05/05/18 Installing Credential Manager 16:18:05 05/05/18 ./setup_cred_mgr.properties Properties not found. Interactive setup commencing... 16:19:49 05/05/18 Checking properties 16:19:55 05/05/18 Downloading files 16:19:55 05/05/18 Calculating memory setting for applications 16:19:55 05/05/18 Rendering templates 16:19:55 05/05/18 Rendering template cred-manager 16:19:55 05/05/18 Rendering template cred-manager.json 16:19:55 05/05/18 Configuring Credential manager... 16:19:55 05/05/18 Copied ./output/result/cred-manager.json to /etc/gluu/conf 16:19:55 05/05/18 Copying cred-manager.war into jetty webapps folder... 16:19:55 05/05/18 Installing jetty service cred-manager... 16:19:55 05/05/18 Preparing cred-manager service base folders 16:19:55 05/05/18 Running: /bin/mkdir -p /opt/gluu/jetty/cred-manager 16:19:55 05/05/18 Preparing cred-manager service base configuration 16:19:55 05/05/18 Running: /opt/jre/bin/java -jar /opt/jetty/start.jar jetty.home=/opt/jetty jetty.base=/opt/gluu/jetty/cred-manager --add-to-start=deploy,http,logging,jsp,http-forwarded 16:19:55 05/05/18 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 16:19:55 05/05/18 Running: /bin/chown -R jetty:jetty /opt/gluu/jetty/cred-manager 16:19:55 05/05/18 Rendering template cred-manager 16:19:55 05/05/18 Copied ./output/jetty/cred-manager to /etc/default 16:19:55 05/05/18 Running: /bin/chown root:root /etc/default/cred-manager 16:19:55 05/05/18 Copied /opt/jetty/bin/jetty.sh to /etc/init.d/cred-manager 16:19:55 05/05/18 Running: sed -i s/^# Provides: jetty/# Provides: cred-manager/ /etc/init.d/cred-manager 16:19:55 05/05/18 Running: /usr/sbin/update-rc.d cred-manager defaults 60 20 16:19:55 05/05/18 Copied /opt/dist/gluu/cred-manager.war to /opt/gluu/jetty/cred-manager/webapps 16:19:55 05/05/18 Copied /opt/dist/gluu/twilio-7.17.0.jar to /opt/gluu/jetty/oxauth/custom/libs 16:19:55 05/05/18 Running: /bin/chown -R jetty:jetty /opt/gluu/jetty/oxauth/custom/libs 16:19:55 05/05/18 Error reading None 16:19:55 05/05/18 Traceback (most recent call last): File "/install/community-edition-setup/setup.py", line 763, in readFile f = open(inFilePath) IOError: [Errno 2] No such file or directory: '/etc/redhat-release' 16:19:55 05/05/18 Found package '/opt/dist/oxd/oxd-server_3.1.2-8~xenial+Ub16.04_all.deb' for install 16:19:55 05/05/18 Running: /usr/bin/dpkg --install /opt/dist/oxd/oxd-server_3.1.2-8~xenial+Ub16.04_all.deb 16:20:00 05/05/18 Selecting previously unselected package oxd-server. (Reading database ... 18440 files and directories currently installed.) Preparing to unpack .../oxd-server_3.1.2-8~xenial+Ub16.04_all.deb ... Unpacking oxd-server (3.1.2-8~xenial+Ub16.04) ... Setting up oxd-server (3.1.2-8~xenial+Ub16.04) ... Processing triggers for systemd (229-4ubuntu16) ... 16:20:00 05/05/18 Running: chmod 644 -R /etc/oxd/oxd-server/oxd-conf.json 16:20:00 05/05/18 Running: /usr/sbin/update-rc.d oxd-server defaults 50 25 16:20:00 05/05/18 Running: chmod +x /opt/oxd-server/bin/oxd-start.sh 16:20:00 05/05/18 Running: /usr/sbin/service oxd-server start 16:20:01 05/05/18 Run: /usr/sbin/service oxd-server start with result code: 0 16:20:01 05/05/18 Running: /bin/chown -R root:jetty /etc/gluu/conf/cred-manager.json 16:20:01 05/05/18 Running: /bin/chmod g+w /etc/gluu/conf/cred-manager.json 16:20:01 05/05/18 Importing LDIF files into LDAP 16:20:01 05/05/18 Importing LDIF file './output/scripts_cred_manager.ldif' into OpenLDAP 16:20:01 05/05/18 Running: /bin/su ldap -c cd /install/community-edition-setup; /opt/symas/bin/slapadd -b o=gluu -f /opt/symas/etc/openldap/slapd.conf -l ./output/scripts_cred_manager.ldif 16:20:01 05/05/18 Running: /usr/sbin/service oxauth restart 16:20:18 05/05/18 Run: /usr/sbin/service oxauth restart with result code: 0 16:20:18 05/05/18 Running: /usr/sbin/service cred-manager start 16:20:28 05/05/18 Run: /usr/sbin/service cred-manager start with result code: 0 16:20:28 05/05/18 Running: mv -f /etc/rc3.d/S*cred-manager /etc/rc3.d/S97cred-manager 16:20:28 05/05/18 Run: mv -f /etc/rc3.d/S*cred-manager /etc/rc3.d/S97cred-manager with result code: 0 16:20:28 05/05/18 Running: mv -f /etc/rc3.d/S*oxd-server /etc/rc3.d/S91oxd-server 16:20:28 05/05/18 Run: mv -f /etc/rc3.d/S*oxd-server /etc/rc3.d/S91oxd-server with result code: 0 16:20:28 05/05/18 Saving properties to ./setup.properties.last ``` I can now access identity and cred-manager. Looking at oxauth.log, I see: ``` grep ERROR oxauth.log 2018-05-05 16:22:11,914 ERROR [qtp2008017533-10] [xdi.oxauth.authorize.ws.rs.AuthorizeRestWebServiceImpl] (AuthorizeRestWebServiceImpl.java:825) - Failed to load session from LDAP by session_id: '168d484a-eb8e-4dce-b3eb-ebf3d90159a4' ``` Troubling, but it's working. I restart oxauth from within the chroot. Still working. I come out of chroot, stop and start the gluu-server-3.1.2 service, and it comes back 503. Looking at oxauth.log again, I see: ``` 2018-05-05 16:27:23,036 ERROR [qtp2008017533-16] [org.xdi.oxauth.auth.Authenticator] (Authenticator.java:517) - Failed to get attributes from session ``` Not to be deterred, I try stopping and starting oxd-server, oxauth, and cred-manager. Still 503. In total desperation, I restart identity, then oxauth. Gluu comes roaring back to life. I have confirmed that after a gluu-server-3.1.2 service restart, the only way to bring gluu back to life is to restart identity and then oxauth. I'm guessing reworking /etc/init.d/gluu-server-3.1.2 is the fix. Hope this helps.

By Jose Gonzalez staff 06 May 2018 at 10:32 a.m. CDT

Copy
Jose Gonzalez gravatar
Jeff, Thanks a lot for your feedback... and patience. You really got acquaintance with gluu server installation. We will use the valuable information you reported to internally discuss the possible causes of services failure. Before releasing we do a lot of testing, including checks of services survival upon restarts of vm or gluu, and this is the first finding of this kind we see. By chance we are doing in this moment those sort of tests for 3.1.3 (which will be out soon). rpm-based systems are doing well, and deb-based still awaiting QA. If you don't mind, can you paste here the output of the JAVA_OPTIONS line for the following commands: ``` service cred-manager status service identity status service oxauth status ``` Can we know the amount of RAM you used for your VM? Kind regards, Jose

By Jeff E Mandel user 06 May 2018 at 10:45 a.m. CDT

Copy
Jeff E Mandel gravatar
service cred-manager status ``` JAVA_OPTIONS = -server -Xms256m -Xmx357m -XX:MaxMetaspaceSize=154m -XX:+DisableExplicitGC -Dgluu.base=/etc/gluu -Dserver.base=/opt/gluu/jetty/cred-manager -Dlog.base=/opt/gluu/jetty/cred-manager -Djetty.logging.dir=/opt/gluu/jetty/cred-manager/logs -Djetty.home=/opt/jetty -Djetty.base=/opt/gluu/jetty/cred-manager -Djava.io.tmpdir=/opt/jetty-9.3/temp JETTY_ARGS = jetty.http.host=localhost jetty.http.port=8091 jetty.state=/opt/gluu/jetty/cred-manager/cred-manager.state jetty-logging.xml jetty-started.xml ``` service identity status ``` JAVA_OPTIONS = -server -Xms256m -Xmx858m -XX:MaxMetaspaceSize=368m -XX:+DisableExplicitGC -Dgluu.base=/etc/gluu -Dserver.base=/opt/gluu/jetty/identity -Dlog.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 ``` service oxauth status ``` JAVA_OPTIONS = -server -Xms256m -Xmx1288m -XX:MaxMetaspaceSize=552m -XX:+DisableExplicitGC -Dgluu.base=/etc/gluu -Dserver.base=/opt/gluu/jetty/oxauth -Dlog.base=/opt/gluu/jetty/oxauth -Dpython.home=/opt/jython -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 ``` Base memory: 4096 Processors: 2 ``` $ free -m total used free shared buff/cache available Mem: 3951 2575 177 5 1198 1111 Swap: 4092 3 4089 ```

By Jose Gonzalez staff 09 May 2018 at 8:58 a.m. CDT

Copy
Jose Gonzalez gravatar
Hi Jeff, Data you provided looks fine. We tried to replicate your problem in 3.1.2 but it wasn't possible. We did extensive testing for 3.1.3 as well, and were unable to make services fail upon reboots or gluu-server restarts ... Maybe you'd like to try the [latest available version](https://gluu.org/docs/creds/3.1.3). Installation steps are the same. However, you will have to use Gluu Server 3.1.3. If you do, I'd suggest to play with restarts before you proceed with cred-manager instalation.

By Jeff E Mandel user 09 May 2018 at 6:14 p.m. CDT

Copy
Jeff E Mandel gravatar
I'll try it out this weekend. In the interim, could you explain how to modify the init.d script to restart identity and oxauth? I'm pretty sure I'm neither the first nor the last person to have to deal with this issue. Thanks!

By Jose Gonzalez staff 10 May 2018 at 2:05 p.m. CDT

Copy
Jose Gonzalez gravatar
Hi, I am not totally sure about the tweak you want to implement in the script. Can you elaborate a bit more?. Anyways, we'll make one of the script implementors to pitch in the discussion. By now I'd suggest to revert to 3.1.2 original script which you can find [here](https://raw.githubusercontent.com/GluuFederation/community-edition-package/version_3.1.2/package/initd/gluu-server). This won't interfere with cred-manager related stuff actually. The modification in the script that the installation docs suggest is just to ensure that oxd-server stops when the gluu server is going down as well.

By Ganesh Dutt Sharma Account Admin 18 May 2018 at 6:12 a.m. CDT

Copy
Ganesh Dutt Sharma gravatar
Hi Jeff, Gluu Server init script is set to start anything inside chroot at rc3 level. So you should not need to do anything except ensuring that cred-manager is set to run in level 3 automatically inside chroot.

By Jeff E Mandel user 03 Jun 2018 at 1:03 p.m. CDT

Copy
Jeff E Mandel gravatar
OK, I found the problem. At some point, I installed gluu-server-3.1.1 on the main server, rather than on the VM. I think this was so that I could localize the login screen. I subsequently removed /opt/gluu-server-3.1.1, but it didn't occur to me to remove /etc/init.d/gluu-server-3.1.1. I discovered this yesterday, and simply disabled the service, rebooted, and now everything works. I didn't explore what was causing identity to die, but resurrect when explicitly restarted, but needless to say, don't do this!

Post an answer