Support Questions

Find answers, ask questions, and share your expertise

Cloudera Manager using SSL failed, how to revert changes?

avatar
New Contributor

Dear Community,

 

My first post here and experiencing my first carefull steps into the world of Cloudera. But during confguration I messed up. Using the installation guide of Cloudera Manager version 6.0x I followed the steps to get the admin GUI only entered via HTTPS. After restarting the Cloudera server I can not enter the admin GUI via port 7183 and of course not anymore on port 7180. I read a lot about reverting changes to get into the GUI again but all solutions regarding entering the embedded postgress database which I can, but any changes I try to make ends into errors like "relation.... does not exists". My question is how I can revert TLS / SSL changes so I can enter the administration GUI again. As a beginner I think I need to a more detailed explanation then for example delete from CONFIGS where ATTR='TLS setting' or something like that, a big sorry for that.

 

Thanks in advance and kind regards,

 

AadD

1 ACCEPTED SOLUTION

avatar
Master Guru

@AadD,

 

Thanks for trying out Cloudera; sorry that it has been a rocky start, but you came to the right place for help.

 

We'll need some information in order to assist:

 

- What steps did you follow to intall? What documentation? (list specific URLs if you can)

- What steps did you follow to enable TLS? (list specific URLs if you can)

- Did Cloudera Manager ever start and allow you to access it on port 7180? (http://cm_host:7180?)

- How do you know that Cloudera Manager running or responding to HTTP requests?  What did you do to test?

- If you ssh to the host where Cloudera Manager should be running, is it listening on port 7180?  7183? 7182?

 

Run:

# netstat -nap |grep 7180;netstat -nap |grep 7183; netstat -nap |grep 7182

 

- If the problem is with TLS, then the following steps will turn off the TLS port for the Cloudera Manager User Interface:

 

(1)

 

Review your Cloudera Manager database configuration:

 

# cat /etc/cloudera-scm-server/db.properties

 

(2)

 

Use the information in db.properties to run the psql command:

 

For example, this is how I would connect on my host:

 

- I see the following in db.properties:

 

com.cloudera.cmf.db.type=postgresql
com.cloudera.cmf.db.host=localhost:7432
com.cloudera.cmf.db.name=scm
com.cloudera.cmf.db.user=scm
com.cloudera.cmf.db.password=FpZ3wh9LFT
com.cloudera.cmf.db.setupType=EMBEDDED

 

(3)

 

Use the db.properties information to connect to your database

 

For example:

 

- Based on the information in my environment, that would be:

 

# psql -U scm -h localhost -p 7432

Password for user scm: FpZ3wh9LFT
psql (9.2.18)
Type "help" for help.

scm=>

 

(4)

 

Check the configuration that governs TLS for Cloudera Manager and Cloudera Manager agent communication:

 

scm=> select * from configs where attr = 'web_tls';

scm=> select * from configs where attr = 'agent_tls';

 

(5)

 

If any rows are returned from the above commands, delete them:

 

scm=> delete from configs where attr = 'web_tls';

scm=> delete from configs wehre attr = 'agent_tls';

 

Search again to verify that no rows are returned:

 

scm=> select * from configs where attr = 'web_tls';

scm=> select * from configs where attr = 'agent_tls';

 

(6)

 

If there are no rows returned, restart Cloudera Manager with:

 

# service cloudera-scm-server restart

 

(7)

 

CM can take minutes to start, so wait about 5 to be sure and then run the netstats again.

If you see that CM is listening on port 7182 (agent communication) and 7180 (non-tls web ui) then try accessing it via your browser.

 

If CM still fails to start, review the Cloudera Manager log.

On the Cloudera Manager host it is by default:

 

/var/log/cloudera-scm-server/cloudera-scm-server.log

 

Let us know how it goes.

 

Cheers,

 

Ben

View solution in original post

4 REPLIES 4

avatar
New Contributor

Dear community,

 

Update: I managed to get the queries like delete from configs where ATTR='xxxx_tls' but after restart I still can not reach the Cloudera Manager portal. What do I need to do to get really inverted the SSL configuration so I can enter the portal with port 7180 and HTTP again?

 

Thanks in advance and kind regards,

 

AadD

avatar
Master Guru

@AadD,

 

Thanks for trying out Cloudera; sorry that it has been a rocky start, but you came to the right place for help.

 

We'll need some information in order to assist:

 

- What steps did you follow to intall? What documentation? (list specific URLs if you can)

- What steps did you follow to enable TLS? (list specific URLs if you can)

- Did Cloudera Manager ever start and allow you to access it on port 7180? (http://cm_host:7180?)

- How do you know that Cloudera Manager running or responding to HTTP requests?  What did you do to test?

- If you ssh to the host where Cloudera Manager should be running, is it listening on port 7180?  7183? 7182?

 

Run:

# netstat -nap |grep 7180;netstat -nap |grep 7183; netstat -nap |grep 7182

 

- If the problem is with TLS, then the following steps will turn off the TLS port for the Cloudera Manager User Interface:

 

(1)

 

Review your Cloudera Manager database configuration:

 

# cat /etc/cloudera-scm-server/db.properties

 

(2)

 

Use the information in db.properties to run the psql command:

 

For example, this is how I would connect on my host:

 

- I see the following in db.properties:

 

com.cloudera.cmf.db.type=postgresql
com.cloudera.cmf.db.host=localhost:7432
com.cloudera.cmf.db.name=scm
com.cloudera.cmf.db.user=scm
com.cloudera.cmf.db.password=FpZ3wh9LFT
com.cloudera.cmf.db.setupType=EMBEDDED

 

(3)

 

Use the db.properties information to connect to your database

 

For example:

 

- Based on the information in my environment, that would be:

 

# psql -U scm -h localhost -p 7432

Password for user scm: FpZ3wh9LFT
psql (9.2.18)
Type "help" for help.

scm=>

 

(4)

 

Check the configuration that governs TLS for Cloudera Manager and Cloudera Manager agent communication:

 

scm=> select * from configs where attr = 'web_tls';

scm=> select * from configs where attr = 'agent_tls';

 

(5)

 

If any rows are returned from the above commands, delete them:

 

scm=> delete from configs where attr = 'web_tls';

scm=> delete from configs wehre attr = 'agent_tls';

 

Search again to verify that no rows are returned:

 

scm=> select * from configs where attr = 'web_tls';

scm=> select * from configs where attr = 'agent_tls';

 

(6)

 

If there are no rows returned, restart Cloudera Manager with:

 

# service cloudera-scm-server restart

 

(7)

 

CM can take minutes to start, so wait about 5 to be sure and then run the netstats again.

If you see that CM is listening on port 7182 (agent communication) and 7180 (non-tls web ui) then try accessing it via your browser.

 

If CM still fails to start, review the Cloudera Manager log.

On the Cloudera Manager host it is by default:

 

/var/log/cloudera-scm-server/cloudera-scm-server.log

 

Let us know how it goes.

 

Cheers,

 

Ben

avatar
New Contributor

Bgooley,

 

Thanks for your reply and vast explanation how to roll back an failed TLS configuration. It did the trick and I can go on. A new challenge arose, correct certificates within an own keystore. But for now I am totally happy to have a workaround to get / keep Cloudera alive when failing TLS.

 

Kind regards,

 

AadD

avatar
Master Guru

@AadD,

 

If you can post the command(s) you used to create the CM private key and cert that would help.

Also, if you can share the output for keytool -list -v -keystore <keystore> that could help.

 

Generally, if the server won't start at all, there is a problem with a password or permissions on the JKS file you are using for your Key file or truststore.

 

When implementing for the first time, only enable TLS for the CM admin console (UI).  If there is a problem using a certificate, it should start up using non-tls and warn you that something's wrong.

 

Check /var/log/cloudera-scm-server/cloudera-scm-server.log for exceptions or messages pertaining to SSL/TLS.

 

Cheers,

 

Ben