I installed Archiva 1.4-M4, and tried to access its REST API, beginning with the simple ping service, using curl;
$ curl http://localhost:8080/restServices/pingService/ping
<html><body>No service was found.</body></html>
Perhaps some configuration needs to be set to enable the services, but I can't find anything in the documentation that indicates such. It does say there should be a .wadl file in the distribution, but I can't find one in the install directories.
How do I get started with this?
Try
http://localhost:8080/restServices/archivaServices/pingService/pingenter
See wadl files: http://localhost:8080/restServices/
If installed as root context! If not http://localhost:8080/${yourContext}/...
Related
I'm pretty new to Kubernetes and clusters so this might be very simple.
I set up a Kubernetes cluster with 5 nodes using kubeadm following this guide. I got some issues but it all worked in the end. So now I want to install the Web UI (Dashboard). To do so I need to set up authentication:
Please note, this works only if the apiserver is set up to allow authentication with username and password. This is not currently the case with the some setup tools (e.g., kubeadm). Refer to the authentication admin documentation for information on how to configure authentication manually.
So I got to read authentication page of the documentation. And I decided I want to add authentication via a Static Password File. To do so I have to append the option --basic-auth-file=SOMEFILE to the Api server.
When I do ps -aux | grep kube-apiserver this is the result, so it is already running. (which makes sense because I use it when calling kubectl)
kube-apiserver
--insecure-bind-address=127.0.0.1
--admission-control=NamespaceLifecycle,LimitRanger,ServiceAccount,PersistentVolumeLabel,DefaultStorageClass,ResourceQuota
--service-cluster-ip-range=10.96.0.0/12
--service-account-key-file=/etc/kubernetes/pki/apiserver-key.pem
--client-ca-file=/etc/kubernetes/pki/ca.pem
--tls-cert-file=/etc/kubernetes/pki/apiserver.pem
--tls-private-key-file=/etc/kubernetes/pki/apiserver-key.pem
--token-auth-file=/etc/kubernetes/pki/tokens.csv
--secure-port=6443
--allow-privileged
--advertise-address=192.168.1.137
--kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname
--anonymous-auth=false
--etcd-servers=http://127.0.0.1:2379
Couple of questions I have:
So where are all these options set?
Can i just kill this process and restart it with the option I need?
Will it be started when I reboot the system?
in /etc/kubernetes/manifests is a file called kube-apiserver.json. This is a JSON file and contains all the option you can set. I've appended the --basic-auth-file=SOMEFILE and rebooted the system (right after the change of the file kubectl wasn't working anymore and the API was shutdown)
After a reboot the whole system was working again.
Update
I didn't manage to run the dashboard using this. What I did in the end was installing the dashboard on the cluster. copying the keys from the master node (/etc/kubernetes/admin.conf) to my laptop and did kubectl proxy to proxy the traffic of the dashboard to my local machine. Now I can access it on my laptop through 127.0.0.1:8001/ui
I just found this for a similar use case and the API server was crashing after adding an Option with a file path.
I was able to solve it and maybe this helps others as well:
As described in https://kubernetes.io/docs/reference/setup-tools/kubeadm/implementation-details/#constants-and-well-known-values-and-paths the files in /etc/kubernetes/manifests are static pod definitions. Therefore container rules apply.
So if you add an option with a file path, make sure you make it available to the pod with a hostPath volume.
I'm trying to get the tomcat8-keycloak-adapter to accept basic auth as specified in the documentation, by setting enable-basic-auth to true. Instead of working or failing, as expected, this causes the thread to hang until HTTP times out.
Using tcpdump to snoop the HTTP connection between the tomcat adapter and the keycloak server shows that it is never sending the HTTP request. I can find no information about this on the internet, so I am down to the actual point of asking: does "enable-basic-auth" actually work in the tomcat adapter?
Note that I am using keycloak v1.9.8 and matching adpater 1.9.8. adaptever v2.0.0 appears to have difficulty starting up at this time, and we are still using the 1.9 keycloak in production. keycloak is the official docker image, tomcat is manually installed into the official tomcat8 docker image, using jre8.
It works for me in a Jetty setup. A hanging request indicates a networking problem to me. You question indicates that you are using docker.
The Tomcat inside its docker container needs to contact Keycloak as configured by the URL auth-server-url in the file keycloak.json.
I suspect that the Tomcat can't reach this URL. Please try to reach the URL as stated in keycloak.json from within the Tomcat's docker container, for example via curl --verbose ...
I am trying to automatically deploy our Java EE application from our build server (Jenkins) to a remote Glassfish server via the command line.
At the moment I am using asadmin for this and it works fine, but this option requires me to have Glassfish installed on the build server as well - which I would like to avoid as I do not need it there. The build server is really only running the builds and the deployment so I would like to keep the server as "clean" as possible.
I can't find any download that installs only the asadmin tools, and also my attempt to manually copy over only the required files failed as there are some dependencies to certain *.jars that I don't know of so it always fails unless I copy the whole glassfish installation folder to the build server.
So my question is:
Does anybody know how to install only the asadmin tools without installing the whole Glassfish server?
Alternatively I would also be happy to use any other command line tools as long as they allow me to deploy to a remote Glassfish instance using secure communication.
After doing a bit more research I gave up on trying to install asadmin without the full Glassfish installation and instead used Glassfish's REST admin interface.
I now made it work using CURL in a simple batch file:
curl.exe ^
--user glassfish_username:glassfish_password ^
--insecure ^
-H "Accept: application/json" ^
-H "X-Requested-By: dummy" ^
-X POST ^
-F id=#yourfile.war ^
-F contextroot=yourcontextroot ^
-F force=true ^
https://yourservername:4848/management/domain/applications/application/
The REST API is fairly straight forward once you know what you need to do but just in case somebody else needs this, here a couple of important points:
--insecure is required (by CURL) to allow self-signed and untrusted SSL certificates
The header attributes for "Accept" and "X-Requested-By" must be set, otherwise Glassfish doesn't process the request and simply returns a blank document as an ansower. No idea why but setting these parameters made it work.
The content of the war
file is passed as the "id" parameter on the POST
The URL needs to be exactly as shown in the snipped above, i.e. do not replace "domain"
with your domain name or "application" with your application name. This is the actual REST interface endpoint. There is no need to specify the domain/application name anywhere.
So I have managed it. I can clone mercurial-repositories remotely using HTTP to my Windows Server 2003 machine and the ipaddress from that machine. Although I did deactivate IIS6 and am using Apache 2.2.x now. But not all works right now...darn! Here's the thing:
Cloning goes smooth! But when I want to push my changes to the original repository I get the message "cannot lock static http-repository". On the internet I get to read several explanations that Mercurial wasn't designed to push over HTTP connections. Still, on the Mercurial website there's something about configuring an hgrc file.
There's also the possibilty to configure Apache to host via HTTPS (or SSL). For this you have to load the module enabling OpenSSL and generating keys.
Configuring the hgrc file
Just add "push_ssl = false" under the [web] line. But where to put this file when pushing your changes back?! Because I placed it in the root of the server, in the ".hg" directory, nothing works.
Using SSL/HTTPS with Apache
When I try to access 'https://myipaddress' it fails, displaying a dutch message which would mean something like "server taking too long to respond". Trying to push also gives me a dutch error message which means about the same. It can not connect to my server via https although I followed the steps exactly at this blog.
I don't care which of the above solutions will work for me. Turns out none of them work so far. So please, can anyone help me with one of the solutions above? Pick the easiest! Help will be greatly appreciated, not only from me.
Summary
-Windows Server 2003
-Apache 2.2 with OpenSSL
-Mercurial 1.8.2
-I can clone, but not push!
Thank you!
Maarten Baar(s)
It seems like you might have apache configured incorrectly for getting it to do what you want. Based on your question it sounds like you have a path (maybe the root of the server) pointing to the repository you want to serve.
Mercurial comes with a script for this exact purpose, in the latest version it is hgweb.cgi. There are reasonably good instructions for setting it up on the mercurial site. It should allow both cloning and pushing. You will need the push_ssl=false if you will not be configuring https and also an allow_push line which will let certain users, or all (*) push to the repository. But all that should be part of the setup docs.
We developed a web service client application using the wsdls from the url location.
I don't want the webservice client to go and validate the actual wsdls everytime , so wanted to download the wsdls in to local project .
is there any way can i download the wsdls using maven similar to copy resources?
Thanks
Vijay
You can use the wagon plugin to download the files to your project. See its usage page.
Two cases. If you own the service code, and it's something like Apache cxf, there's a command line like java2wsdl or java2ws. In the case of CXF, there's even a maven plugin for the job already.
If the service is 'out there' somewhere, you could use the linux wget or curl commands to fetch the wsdl from the ?wsdl URL.