Member since
05-07-2015
9
Posts
0
Kudos Received
2
Solutions
My Accepted Solutions
Title | Views | Posted |
---|---|---|
2334 | 03-04-2021 09:18 AM | |
5108 | 06-17-2015 02:00 PM |
03-10-2021
06:36 AM
Hello, Not sure what URL you're referring to, but as mentioned in my original post, after googling for the documentation I found myself here: https://docs.cloudera.com/documentation/enterprise/upgrade/topics/ug_cdh_upgrade.html "Upgrading the CDH Cluster" It had the link "Updating an existing CDH/Cloudera Manager deployment to access downloads with authentication." - which was broken, giving a 404. I raised a ticket with Cloudera support and told them all of this. I was given an alternative URL to try - not the one that ended up working, and which did not work. I found the link myself and have since upgraded 2 clusters. After seeing your update here today, I went back to the original page I was looking at: https://docs.cloudera.com/documentation/enterprise/upgrade/topics/ug_cdh_upgrade.html And see now that the link has been fixed, maybe because of my ticket in which I requested as much. The page that I now arrive at does indeed contain the correct link that I had previously found manually. Therefore there is no longer any issue, but if you want to pass some feedback then "thanks for fixing the broken link" will probably do! Thanks again for you attention to this thread, it is appreciated.
... View more
03-04-2021
11:33 AM
Not a network/proxy issue. As described in my original post I had no problem with the URL in a browser or using wget. The problem is with Cloudera's documentation.
... View more
03-04-2021
09:18 AM
Hi, Thanks for the reply. Yes as I mention I have complete access through a browser to navigate around the filesystem as it is presented. I was able to download the 'index.html' page using wget, so I assume I would be able to download other items using wget. Since posting the above I went and looked at the logs on disk. It was complaining about not being able to see the file manifest.json, a 404 was being returned. So I went back to the browser and clicked around until I found that file, and used that URL, which was: https://<REDACTED>@archive.cloudera.com/p/cdh6/6.3.4/parcels/ When I saved that in CM, the new parcel became immediately available. I have not seen that URL given in any documentation. Though that said, the documentation under https://docs.cloudera.com/documentation/enterprise/upgrade/topics/ug_cdh_upgrade.html contains a link that states: For more information, see Updating an existing CDH/Cloudera Manager deployment to access downloads with authentication. in a section about the paywall. If you follow that link, you will get a 404. I raised this in my ticket and was told instead to go to: https://docs.cloudera.com/documentation/enterprise/6/release-notes/topics/cm-retrofit-auth-downloads.html which led me here: https://docs.cloudera.com/documentation/enterprise/6/release-notes/topics/rg_cm_6_version_download.html#cm_6_version_download which gives this version of the URL: https://<login>archive.cloudera.com/p/cm6/6.3.4/ubuntu1804/apt/ which is different again, and seems to reference CM as opposed to CDH. I don't think I can effectively test this link in my clusters as I already have the parcels downloaded via the other URL that I had worked out manually. I'm surprised given all the above that this problem hasn't been reported already. I saw lots of tickets from people who were no longer able to access the parcels after the paywall went up, either because they didn't have a license or had not yet obtained their paywall login, but nothing reporting this problem. Perhaps there is some different way I should have gone about it, but all my attempts were via the online docs and the support personnel, and in the end I had to sort it out by myself.
... View more
03-04-2021
06:24 AM
We have a valid license and and login to the paywall, which I have tested by using parcel URLs in a browser and from the command line (Ubuntu) with wget. Both show I can obtain a directory listing from behind the paywall. However, despite entering this URL in the configuration for the Parcel window in CM, I still do not see new available parcels. We are on 6.3.1 on one cluster and 6.3.2 on another, it's the same for both, no new parcels listed. We presumably should see at least 6.3.4, if not 6.3.3 as well. I first tried with the URL format given by the documentation (obviously replacing username:password with our actual info), and a slightly different URL I was given in a support ticket I raised. I get no errors, but still no new parcels showing as available. Has anyone else experienced this?
... View more
Labels:
- Labels:
-
Cloudera Manager
06-17-2015
02:00 PM
I realised the problem. My /etc/hosts file on the AWS cluster nodes needed to contain references to each other. I had added references to the source cluster nodes, but the AWS nodes needed to be in there too.
... View more
06-17-2015
12:18 PM
Thanks Gautam, Yes both 'DNS Resolution' and 'DNS Hostnames' are set to YES for the VPC Paul
... View more
06-17-2015
12:09 PM
We are currently trying to set up HBase replication from a cluster on our own hardware, to a new one on our VPC on Amazon AWS (for disaster recovery). The Amazon nodes have Private DNS like: ip-10-3-1-61.us-west-2.compute.internal and Private IPs like 10.3.1.61 All nodes on our hardware can ping, ssh, telnet etc to the Amazon nodes (using the IP or FQDN), and vice versa. There are entries in the /etc/hosts files on all servers on both sides to ensure resolution. Our servers are running Ubuntu 12.04, the AWS ones are Red Hat 6. Both clusters are running HBase 0.98.6, both have replication set to true. The tables we want replicated have replication_scope set to 1. I've added the peer entry in hbase shell. So everything seems good. However, when I start replication I see this in the Hbase logs on the master side: 2015-06-16 12:37:15,643 WARN org.apache.hadoop.hbase.replication.regionserver.ReplicationSource: Can't replicate because of a local or network error: java.net.UnknownHostException: unknown host: ip-10-3-1-62.us-west-2.compute.internal at org.apache.hadoop.hbase.ipc.RpcClient$Connection.<init>(RpcClient.java:385) at org.apache.hadoop.hbase.ipc.RpcClient.createConnection(RpcClient.java:351) at org.apache.hadoop.hbase.ipc.RpcClient.getConnection(RpcClient.java:1530) at org.apache.hadoop.hbase.ipc.RpcClient.call(RpcClient.java:1442) at org.apache.hadoop.hbase.ipc.RpcClient.callBlockingMethod(RpcClient.java:1661) at org.apache.hadoop.hbase.ipc.RpcClient$BlockingRpcChannelImplementation.callBlockingMethod(RpcClient.java:1719) at org.apache.hadoop.hbase.protobuf.generated.AdminProtos$AdminService$BlockingStub.replicateWALEntry(AdminProtos.java:21036) at org.apache.hadoop.hbase.protobuf.ReplicationProtbufUtil.replicateWALEntry(ReplicationProtbufUtil.java:65) at org.apache.hadoop.hbase.replication.regionserver.ReplicationSource.shipEdits(ReplicationSource.java:730) at org.apache.hadoop.hbase.replication.regionserver.ReplicationSource.run(ReplicationSource.java:388) I understand the error, I just don't understand how it's getting it. What process is not able to resolve the hostname? Any ideas? Thanks in advance, Paul
... View more
Labels:
- Labels:
-
Apache HBase