I'm trying out Fabric8 V2 on OpenShift V3 using Docker (version 1.5, native install, on Ubuntu 14.04).
I've followed the guide at http://fabric8.io/v2/openShiftDocker.html and used bash <(curl -sSL https://bit.ly/get-fabric8) -k to setup everything.
At the end of the procedure, a new tab opens in browser at http://172.30.17.152/kubernetes/overview which is immediately redirected to an OAuth page, but the URL is incomplete (missing the host part and possibly a port number).
The URL was: https://oauth/authorize?client_id=fabric8-console&response_type=token&state=http%3A%2F%2F172.30.17.152%2Fkubernetes%2Foverview&redirect_uri=http%3A%2F%2F172.30.17.152%2Fkubernetes%2Foverview
Any ideas?
This question is obsolete. Please try with a newer release.
Related
W0111 13:21:23.866650 172 azure.go:92] WARNING: the azure auth plugin is deprecated in v1.22+, unavailable in v1.26+; use https://github.com/Azure/kubelogin instead.
To learn more, consult https://kubernetes.io/docs/reference/access-authn-authz/authentication/#client-go-credential-plugins
This is the error I get in cmd, powershell, git-bash, azure shell & vscode terminal. Also I get the same issue if I go to the azure portal and use the web shell.
Yes if I use the terminal in Mirantis lens kubectl works as expected the only difference being is that I've added a http proxy in the Proxy settings for Lens.
I belive the issue is caused by the terminal not using the http proxy.
I've added a system environment variable through advanced system settings, which doesn't appear to be used in my terminal session.
How can I use the http proxy during sessions to use kubectl to access AKS and how can I check if the terminal is using the http proxy?
Installed kubelogin as above
Checked that the proxy was running using Get-Proxess px*
Checked that the environment variable was set with the correct value by doing ls $env: and listing all envvars
You are correct, the problem is with the client.
It seems you are using a client version > 1.26, which as the error suggests its removed.
The easiest thing you can do is to use an older version of the kubectl client.
I have installed knox server and done all the steps mentioned on hortonworks site.
When i ran the below command on the sandbox , it gives me the proper output.
curl http://sandbox:50070/webhdfs/v1?op=GETHOMEDIRECTORY
Now i have another VM running fedora . I am assuming it as external client and trying to do external access but getting no output:-
curl -k https://<sandbox-ip>:8443/gateway/sandbox/webhdfs/v1?op=GETHOMEDIRECTORY
Can someone point me whats wrong with my settings.
Not sure about your topology but if you are using the default one (sandbox) you probably need to add basic auth e.g.
curl -k -u guest:guest-password -X GET https://<sandbox- ip>:8443/gateway/sandbox/webhdfs/v1?op=GETHOMEDIRECTORY
Also check the logs at
<knox_install>/logs/gateway.log
They should tell you more about what went wrong.
Good luck !
I am trying to push a Windows Core Docker Image into my Docker Hub account. The error message (1) I am getting is:
$ docker push <MY_DOCKER_HUB_USERNAME>/<MY_IMAGE>
The push refers to a repository [docker.io/MY_DOCKER_HUB_USERNAME/MY_IMAGE] (len: 2)
46e2fd82ef4a: Preparing
Error parsing HTTP response: invalid character '<' looking for
beginning of value: "<html><body><h1>403 Forbidden</h1>\nRequest
forbidden by administrative rules.\n</body></html>\n\n"
Before pushing I am getting properly authenticated from my Mac OS X box by means of login usage:
$ docker login --username=<MY_USERNAME> --email=<MY_EMAIL#MY_SERVER.COM>
WARNING: login credentials saved in /Users/<MY_USERNAME>/.docker/config.json
Login Succeeded
Once I am authenticated, I see no point in getting a "403 Forbidden" error from Docker Hub. Also, it is not clear what these "administrative rules" are, but perhaps they are preventing me from getting my image pushed into Docker Hub registry. Please note that my repository is flagged as "public" as well my default policy ("Default Repository Visibility" from "Settings" in Docker Hub Dashboard).
I tried to do the same within my Windows Server Core box and was not able to get authenticated using the same credentials:
C:\>docker login --username=<MY_USERNAME> --email=<MY_EMAIL#MY_SERVER.COM>
Password:
Error response from daemon: Unexpected status code [403] :
<html><body <h1>403 Forbidden</h1>
Request forbidden by administrative rules.
</body></html>
Docker Client Version from Windows Core box:
C:\>docker --version
Docker version 1.10.0-dev, build 59a341e
Docker Client from Mac OS X box:
$ docker --version
Docker version 1.9.1, build a34a1d5
Windows Server Core version:
PS C:\> [System.Environment]::OSVersion.Version
Major Minor Build Revision
----- ----- ----- --------
10 0 10586 0
P.S.: No matter if I try to push from inside of my Mac OS X box (using my Windows Core box exposed API) or straight from inside of my Windows Core box, they will always lead to the same error message (1). It points me that the whole process depends on the authentication by the Windows Server Core box and since it is not properly working the results will always be the same.
The following answer was taken from ServerFault replica post:
At this time, that is expected behavior. Docker is still in the early
stages of Windows development. This documentation specifically states
that commands related to DockerHub are not supported yet. According to
jhowardmsft in #docker-dev (Freenode): "With (Win Server 2016)
Technical Preview 4, it should be able to push to a Docker Trusted
Registry".
Thanks to l0j1k who kindly answered based on a discussion we had in #docker-dev channel from IRC at freenode.
As for windows box while doing docker login I faced such error (guess it is similar):
docker login dockerserver.local:5006
Authenticating with existing credentials...
Login did not succeed, error: Error response from daemon: Get https://dockerserver.local:5006/v1/: unauthorized: HTTP Basic: Access denied
It was solved by running terminal window (cmd shortcut) with administrator rights:
I'm keep getting this error. I have installed heroku toolkit successfully
C:\Users\hp-u>heroku login
Would you like to submit Heroku CLI usage information to better improve the CLI user experience?
[y/N] Y
heroku-cli: Installing core plugins...Error reading plugin heroku-apps.
Reinstalling... Error reading plugin heroku-apps. Reinstalling ... Error reading plugin heroku-apps. Reinstalling
I removed the s from https:// in the value HTTPS_PROXY variable and it worked.
so:
export HTTPS_PROXY="http://myproxy.com:8080"
//instead of
export HTTPS_PROXY="https://myproxy.com:8080"
i.e. somehow the internal college proxy itself might not be able to perform SSL communication
As of the current time of writing (2012-03-05) I'm running the following components:
OSX Lion
Default Apache installation (Apache2)
SSLEngine on Apache is "on" (doing some dev, but not trying to access .net through ssl yet)
Mono 2.10.8
xsp 2.10.2
mod_mono 2.10
I'm an Win/IIS guy so this is all new to me, but trying to get the xsp test ASP.NET app running on my mac (the app is in the xsp folder and is referenced in the mod_mono install guide).
I've run through the INSTALL guide for xsp and mod_mono.
As far as I can tell everything is running. Appache seems to have loaded the mono module, as it's ok with the mono configuration elements in it's httpd.cong file.
However, when I try to browse to an ASP.NET page, for example, the xsp test one (http://127.0.0.1/demo/index.aspx), I get:
Forbidden
You don't have permission to access /demo/index.aspx on this server.
Apache/2.2.20 (Unix) mod_ssl/2.2.20 OpenSSL/0.9.8r DAV/2 mod_mono/2.10 Server at 127.0.0.1 Port 80
The mono_mod troubleshooting guides say this might happen if Apache doesn't have read acess, but read access on the xsp test folder is set to:
everyone: Read & Write
I'm thinking it's not a directory permissions issue?
I wonder if the mono mod isn't running properly so actually Apache is trying to do a directory listing, which would give a 403?
What could be causing this? And is there any way to diagnose if all the mono mod stuff is installed and running correctly with Apache?
thanks
A script might also require execute permission, try from the command line:
chmod +x /path/to/script.aspx
This let's OS X (and other unixes) know that the file can be run.